docs: OS updates steps 3+4 BUILT (11 §8.2/§8.3, §5.6 kernel facts, §5.8 Docker slow lane design), 00/03/07/08 updated, decisions 84-86 (CC unattended), host undo runbook (proved), register: R-841 R-845 R-846 R-850 closed, R-848 R-849 R-851 opened, R-836 R-812 narrowed (332 -> 333); STATUS; live evidence

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

STATUS.md

@@ -2,8 +2,46 @@
 
 **Ready for the first real tester (Tester-2): yes. You confirmed the tunnel route and the connect mails (2026-09-30).**
 
-**Updated 2026-10-04 (afternoon): guest system updates are automatic on the demo boxes. Both demo boxes run
-controller 0.291.0 and host agent 0.140.0. Hub 0.130.0. New installs get golden 0.291.0.**
+**Updated 2026-10-04 (evening): the HOST's security fixes install themselves too, the hub has a fleet view and four
+OS alarms, and the tunnel status is true. Both demo boxes run controller 0.292.0 and host agent 0.141.1. Hub 0.131.1.
+New installs: see the golden line in the section below.**
+
+## Today (2026-10-04, evening): host fixes, the fleet view, a true tunnel status
+
+**Decisions I took myself (you may reverse each):**
+- Only a box the installer itself recorded as "appliance" gets host updates (a record the agent cannot change).
+- The four alarm times: no update run for 7 days; "reboot needed" for 14 days; the demo boxes approve nothing for 7
+  days; a box has fixes nobody approved for 14 days. All four are settings.
+- I released the host agent and the hub a second time today. The first release said "reboot needed" wrongly; the new
+  14-day alarm would then have mailed you about boxes you had already rebooted.
+
+**One decision for you (a safe default if you say nothing) — the Docker engine updates (designed, not built):**
+1. **Turn on Docker's "live-restore" on every box.** With it, a Docker engine update restarts no app (measured: 0
+   restarts). Without it, every app stops for about 30 seconds per engine update.
+   - **A (my pick):** turn it on — in the new-install image and once on existing boxes. It goes on without restarting
+     anything. Cost: it must never be turned off by a plain restart again (that stops every app and starts none).
+   - **B:** leave it off. Every Docker update then means ~30 seconds of every app being down, at night.
+   - **If you say nothing:** nothing changes; Docker updates stay unbuilt.
+
+**What I did:**
+- **The host's Debian fixes now install themselves**, after the guest's, on the same night run, only on appliances,
+  never a kernel or boot package, never a reboot. Proven: demo-felhom installed 108 host fixes and stayed healthy; all
+  108 came from Debian. A box made "ring 1" for a test installed exactly the one approved host version it lacked.
+- **A way to put one host package back by hand** is written and proven on demo-hp (and the test taught it two fixes).
+- **The fleet view** in the hub: one line per box with its updates, "reboot needed since", and the tunnel.
+- **The tunnel status is now true:** running, not running, or unknown. I blocked demo-hp's tunnel: after two reports
+  (about 30 minutes) you got a "tunnel down" mail; when I unblocked it, "recovered". A simply stopped tunnel heals
+  itself within 5 minutes, before the hub can even see it.
+- **The night run is fast:** 23–32 seconds when there is nothing to install (target was under 60).
+- **The kernel test on demo-hp (your two reboots):** Secure Boot works with it, but GRUB's "boot once" does not work
+  on our boxes: the second plain reboot came up on the NEW kernel again. So a new kernel that hangs would stay. That
+  must be solved before kernel updates. demo-hp now runs the newer kernel, healthy. A watchdog chip exists on demo-hp.
+- **Found and fixed during the live test:** "reboot needed" was wrong in two ways (fixed in the second release).
+- **Rows:** 2 closed, 2 opened-and-closed the same day, 3 opened. The list went from 332 to 333.
+
+**Needs you later (nothing breaks if you wait):**
+- **A host that crashes does not restart by itself** (Linux's "panic" setting is off). Changing it changes how every
+  box behaves, so it is your call, together with kernel updates.
 
 ## Today (2026-10-04, afternoon): the guest's security fixes install themselves