mirror of
https://github.com/kuhyx/wake-alarm.git
synced 2026-11-11 17:33:47 +01:00
af07f52af1
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| c1dbdcda22 |
Grade against 3.14 too, not just run on it
`requires-python` and the CI pin already said 3.14, but ruff, mypy and pylint were still grading against 3.10/3.11 -- three tools judging an interpreter nothing runs any more, and ruff withholding the pyupgrade fixes that only become safe at the newer target. `pin_ci_python.py` rewrites these three knobs. What the stale target was hiding: `datetime.timezone.utc` where `datetime.UTC` is now correct (UP017), `socket.timeout` where `TimeoutError` is (UP041), and ruff's stable formatter applying PEP 758 -- `except (A, B):` becomes `except A, B:`. That makes the source 3.14-only at the syntax level, which is what `requires-python = ">=3.14"` already promised; kuhy chose it deliberately over holding ruff a release back (2026-08-29). ruff, ruff-format, mypy --strict and pylint all clean at the new target. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SfnJmxxsZ534AKk16rC2Gr |
|||
| 95be57b575 |
Make the alarm fully automatic and un-weakenable (08:00, earlier-only)
The alarm was opt-in: it only armed when the user tapped "Set Alarm & Sync to PC", so it could be defeated by simply not tapping it, or by cancelling it the night before. It is now automatic and there is no lever a half-asleep user can pull that buys them sleep. - AlarmPolicy bakes the schedule in at 08:00 daily. The only edit the UI offers is moving the NEXT alarm earlier; setEarlier() refuses anything at or after the baseline, and refuses to relax an active override. Earlier-only is the whole design: every available change costs the user sleep. - The ratchet resets after each fire, so an early start is one-shot. A one-way ratchet with no reset is a trap, not a defence — the first 05:00 would otherwise be permanent with no way back short of reinstalling. - load() re-validates the stored value and ignores anything at or after the baseline. SharedPreferences is not a trust boundary. - No cancel. The Kotlin handler is deleted, not just the Dart wrapper, so the capability genuinely does not exist rather than being one invokeMethod away. - Arming happens in main()'s init seam and via AlarmWatchdog, a daily self-rescheduling check that re-arms if nothing is scheduled — closing the gap where a force-stop or a failed re-arm goes unnoticed until the morning it does not ring. BootReceiver re-establishes it, since setInexactRepeating does not survive a reboot. - Publishing to the PC is automatic too; it used to need the same tap. PC half, so the two agree with the network down: - FALLBACK_ALARM_HOUR 13 -> 8, matching the phone's baseline. At 13:00 a Firebase outage silently moved the alarm five hours LATER — the one direction the design refuses to allow. - _trigger._clamp_to_baseline() refuses any resolved alarm later than the baseline, whatever its source. Without it the PC would faithfully reproduce a stale or tampered remote value and the forbidden direction stays reachable through sync. Tests: 465 Python at 100% branch coverage, 79 Dart. Both ratchet directions are covered, per the standing rule about monotonic counters. test_sync.py and test_trigger.py were split (payload, token, CLI, clamp) to stay under the 250-line gate; the split lost indirect coverage of extract_hlc/newest_alarm, which now have direct tests instead. `python -m wake_alarm._sync --show` and `_trigger --dry-run` both re-run and still print real output. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EckWmyfetYq3Mi8MAnUudh |
|||
| e8f50828e6 |
Phase 5: the power button no longer ends the alarm (item 2)
Two defences, because one press and one held press are different problems. **Prevention — _inhibit.py.** A logind block-mode inhibitor on handle-power-key:shutdown:idle, taken while the alarm is audible and released in on_close(). Confirmed on the host before writing it that PowerKeyIgnoreInhibited=no is in force, so no logind.conf drop-in is needed -- and none is added: a drop-in changes the machine permanently, an inhibitor is scoped to the alarm. Verified live: the inhibitor appears in `systemd-inhibit --list` as `wake-alarm ... shutdown:idle:handle-power-key ... block` and disappears on release. The child runs `sleep 7200`, never `sleep infinity`. An orphaned block-mode inhibitor would hold the power button down until reboot -- worse than the bug being fixed -- so it self-terminates, and a stale one is cleared at startup. That cleanup was wrong on the first attempt and the host run caught it: `pkill -f "--who=wake-alarm"` matched the *shell that had just typed the pattern* and killed it, leaving the real inhibitor alive (`killed 0`, one inhibitor still listed). Substring matching is inherently self-matching. Now it lists `pgrep -x systemd-inhibit` and confirms each pid via /proc/<pid>/cmdline. Re-verified: orphan reaped, exactly one live inhibitor, zero remaining after release. **Consequence — _alarm_session.py.** The real gap was that nothing on disk ever said "ringing, not yet dismissed": wake_state.json is written only on dismissal, so a hard power-off left no trace and the catch-up window closed while the machine was down. A signed record is now written at fire time, and _trigger re-fires on one still marked ringing, ignoring the window. Deliberately no date field. _state.py keys by UTC and screen_locker/_wake_state.py mirrors that helper to read the very same file from another repo, so the UTC basis there is load-bearing. The plan's _today_str() flip is therefore NOT done -- it would have made any dismissal between 00:00-02:00 local read as yesterday's in screen-locker and silently lose an earned workout skip. This record carries only an aware fired_at and compares elapsed time, so the midnight question never arises. Age-bounded at 5400 s: an alarm that dies before dismissal leaves a record nothing ever clears, and unbounded this would restart the alarm every minute forever. Two bugs the unit tests could not see, both found by running it: - A future-stamped record returned None, i.e. "not ringing". But a backward clock jump is routine on a machine that hibernates nightly (NTP correcting after resume), so that failed *open* on exactly the escape it closes: ring on a fast clock, clock corrects, power-off works again. Now clamped to zero within a 900 s tolerance and logged. - _alarm.py derived the correlation id from the alarm's *start* instant. On a catch-up or re-fire the PC would write wake-...-0735 while the phone wrote wake-...-0700 and the two log streams stop joining. Now correlation_id_for_today() derives it from the resolved alarm time, which is what _correlation.py always specified. Every trigger test patched should_refire, so _decide against a real record was untested -- which is why only the manual run found the first one. There is now an end-to-end test that writes a real session and asserts the decision. Splits carried: test_trigger.py 294 -> 197 + test_trigger_main.py, test_alarm_part2.py 266 -> 170 + test_alarm_timers_flash.py. The inhibitor handle moved into _AlarmHardware, which also settles pylint's attribute count and puts it beside the other thing on_close() gives back. No new suppressions: the one inline pylint disable was redundant, since consider-using-with is already disabled repo-wide in pyproject.toml. 452 tests pass, 100% branch coverage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EckWmyfetYq3Mi8MAnUudh |
|||
| f5cfc3e452 |
Phase 1: structured JSONL logging with cross-process dedupe
Adds the diagnostic substrate the rest of the hardening work builds on. A 6am failure should be reconstructable afterwards instead of re-debugged. Two sinks, deliberately. stderr -> journal is unchanged. Alongside it, one JSON object per line in ~/.local/state/wake_alarm/events.jsonl, so a morning can be replayed with jq. The hard constraint is that _trigger is a fresh process every 60 seconds, so an in-memory rate limiter would reset on every tick and suppress nothing. _log_dedupe therefore persists the last emitted fingerprint to disk and flushes a suppressed_repeats count onto the next distinct record. Verified across separate processes: 4 invocations logging the same routine event produce 1 record plus an accurate count of 3. That is what satisfies the standing "do not raise the level of _sync's degraded-read paths" rule by construction, rather than by keeping levels artificially low and losing the signal. The correlation id is derived, never generated: both halves compute wake-YYYYMMDD-HHMM from the resolved alarm instant, so the PC and the phone agree with no handshake and no uuid exchange -- which matters precisely when sync is down. Logging never raises. An unwritable sink degrades to journal-only. _alarm.py and _sync.py keep the default component= for now; tagging them means splitting them for the 250-line gate, which belongs in the phases that actually restructure those files. 389 tests pass, 100% branch coverage held. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EckWmyfetYq3Mi8MAnUudh |
|||
| 87d2629e88 |
Fire the alarm at the phone's time via a per-minute timer
The PC is no longer shut down at night, which broke the scheduling model outright. The wake time used to be decided once, at hibernate, and baked into the RTC by shutdown-wrapper.sh. With no shutdown there is no resume, so sleep-hook.sh never ran and nothing fired the alarm at all. Worse, wake-alarm.service was WantedBy=graphical-session.target and enabled by install.sh, while _should_run_alarm() gates on day / dismissed / workout-logged but has no *time* gate. On an always-on machine that target is reached on every login, so the alarm fired at login time on any alarm day — which is every day. Replace both with a systemd user timer ticking once a minute: - _sync.py reads the alarm the phone pushed to kuhyx/syncs, mirroring shutdown-wrapper.sh's jq parse so the two readers cannot drift. Caches each read, then degrades fresh cache -> fetch -> stale cache -> FALLBACK_ALARM_HOUR, so a network blip can never cost a wake-up. stdlib-only: the units run /usr/bin/python, so a dependency here is a production install-path hazard. - _trigger.py fires morning-routine.service (never wake-alarm.service — that skips the workout lock) when local time is inside [alarm, alarm + TRIGGER_CATCHUP_MINUTES). The catch-up window covers a suspended or just-booted machine; starting an already-active unit is a no-op, so an alarm on screen needs no extra dedupe state. - wake-alarm.service loses its [Install]; install.sh disables it. A timer rather than a resident scheduler: each tick is a fresh process, so there is no daemon to die silently and no wall-clock jump to handle across suspend/resume. Ticks are per-minute for exact-minute firing, but only hit the network when the cache is older than 5 minutes — ~288 GitHub reads/day, and phone changes land within ~5 minutes. Degraded reads log at INFO, not WARNING: at one tick a minute a persistent condition would be 1440 identical journal lines a day. The one WARNING kept is _trigger firing on a non-phone alarm time. Token resolution gains a fallback to the sibling apps' repo-scoped sync_token, in both readers, so one PAT covers every app on kuhyx/syncs. Note this surfaced that wake-alarm-sync/ does not exist in kuhyx/syncs at all: the phone has never completed a push since the crdt_sync migration, so the hibernate path had been silently using the +8h fallback. Fixing that is a phone-side action (reconnect GitHub with repo scope, then one "Set Alarm & Sync"). Alarms edited directly in the Clock app still do not reach the sync — that needs an ACTION_NEXT_ALARM_CLOCK_CHANGED receiver. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
