docs: when a classroom updates, and when it reboots

Daily at 03:00 local time spread over half an hour, caught up once after a
night switched off, on the device's own channel only; and since 0.2.6.5 a
reboot that waits for half an hour with nobody using the computer and
nothing playing. With the journal commands to see each, and the checks
only real hardware can make.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/provisioning.md

@@ -71,6 +71,50 @@ The boot provisioning command never upgrades or reconfigures anything already in
 never touches a repository it did not add. Classroom software updates
 are the OTA channel's job, not this.
 
+## When a classroom updates
+
+**Every day at 03:00**, local time, spread over half an hour so the rooms
+do not all ask at once: `ekklesia-classroom-update.timer`,
+`OnCalendar=*-*-* 03:00:00`, `RandomizedDelaySec=30m`. It has been so
+since 0.1.5; the lab's installed stable machine logged its checks at 03:01
+on 26 September and 03:04 on 27 September.
+
+**A computer that was switched off at 03:00** checks once, soon after it
+is next switched on (`Persistent=true`). Measured on the lab's systemd
+with the machine really stopped across the time: the missed check ran 50 s
+after it started, once, and not again. Nothing else starts the check —
+no boot trigger, no repeat — so it cannot loop.
+
+Each check follows only the device's own `CHANNEL` (a stable room stays
+on stable), installs only a newer version, and only a package whose
+SHA-256, name and version are what the manifest says.
+
+**The reboot after an update waits for nobody to be using the computer**
+(since 0.2.6.5). It used to happen the moment the update was installed:
+harmless at 03:00, and a room restarting itself mid-morning after a night
+switched off. Now `classroom-reboot-when-idle` reboots once no keyboard,
+mouse, touchpad or touchscreen has been touched for 30 minutes *and* no
+sound has played for as long — a video to the room is not an idle
+computer. At 03:00 that is about 03:30. Switched off before then, nothing
+is lost: the update is installed and the next start is on it. Until the
+reboot the session carries on as it was; the only other thing an update
+starts at once, provisioning, does nothing on a machine that is already
+set up.
+
+Input is read from the kernel's input devices, whatever the desktop is
+doing; sound from the kernel's own playback state (`/proc/asound`). Both
+measured in the lab — a mouse made with `/dev/uinput` kept it from
+rebooting, and leaving it alone let it — except the sound card, which the
+lab does not have: that is a check on real hardware.
+
+The schedule is a file the package installs, not a configuration file,
+so every upgrade brings the packaged schedule. The release gate checks it
+after a fresh install and after each upgrade.
+
+    systemctl list-timers ekklesia-classroom-update.timer   # next and last check
+    journalctl -u ekklesia-classroom-update                 # what each check did
+    journalctl -u ekklesia-classroom-reboot-when-idle       # a reboot that is waiting
+
 ## Permanent download addresses
 
 ```

docs/testing.md

@@ -466,7 +466,15 @@ With `LIVE_ENABLED=true`:
 - [ ] `./update_canary.sh` publishes package first, manifest last
 - [ ] The endpoint on the canary channel picks the update up
 - [ ] SHA-256 verification passes
-- [ ] Install succeeds and the endpoint reboots
+- [ ] Install succeeds; `systemctl list-timers ekklesia-classroom-update.timer`
+      shows the next check at about 03:00 tomorrow
+- [ ] (0.2.6.5) Switched on in the morning after a night off, with an update
+      waiting: it installs, `journalctl -u ekklesia-classroom-reboot-when-idle`
+      says it is waiting, and it does **not** restart while you use it
+- [ ] Play a video with sound and leave the mouse alone for 40 minutes: no
+      restart while it plays; half an hour after it stops, it restarts
+- [ ] Left untouched with nothing playing, it restarts about 30 minutes after
+      the update, and comes back on the new version
 - [ ] Everything above still works after the update
 - [ ] Upgrade from 0.1.36 preserves every existing `device.conf` value
 - [ ] `LIVE_ENABLED=false` is appended exactly once on upgrade and remains