From 5c6ec88bb641f89f309debc6676a2c3281ae62a0 Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Thu, 22 Oct 2026 11:05:48 +0200 Subject: [PATCH] docs(architecture): say the timer-vibrate copy runs alongside the boot pass It runs in its own coroutine with no ordering against the engines, not ahead of them. Refs #22 --- docs/ARCHITECTURE.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md index b28a77e..4876d70 100644 --- a/docs/ARCHITECTURE.md +++ b/docs/ARCHITECTURE.md @@ -1911,9 +1911,11 @@ alarm that should buzz the bed and a kitchen timer that should only beep are different questions. Until #22 a timer vibrated exactly when the alarm default did, so nobody's timers change on update: `SettingsPrefs.settleTimerVibrate` copies the alarm default into the new key once, from its own coroutine at -startup (never ahead of the engines' pass), and from then on the two move -apart. The key's own default is `true`, the alarm default's, for the moment -before that lands; a failed copy is tried again on the next launch. Fresh +startup, concurrent with the engines' pass rather than ahead of it, and from +then on the two move apart. The key's own default is `true`, the alarm +default's, for the moment before that lands (a timer that rings in that moment +on the first launch after the update may vibrate once); a failed copy is tried +again on the next launch. Fresh installs therefore start with timer vibration on, like alarms; telling a fresh install from an updated one reliably was more machinery than the default is worth, and the switch is one tap away.