The household is told: controller v0.264.0 + hub v0.120.0 proven live, floor 0.264.0

09 §6.4 parts 2-3 SHIPPED. R-606, R-620, R-646 closed; R-647 (three
leftovers) and R-648 (whole-box backup press in the harness) opened.
Open rows 335 -> 334. Evidence: audits/undo-fleet-2026-09-23/.

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

STATUS.md

@@ -1,26 +1,23 @@
 # STATUS — what works, what's broken, what's next
 
-**Updated 2026-09-23 (afternoon) — a failed update now puts the app back by itself. Built, and proven on the scratch machine. One question for you: whether the fleet gets it.**
+**Updated 2026-09-23 (evening) — the undo is on every demo machine now, and the household gets a mail when an update fails. The floor is raised.**
 
-**Decisions I took on my own: none.** Your two afternoon rulings are written down: the bake-off picks the copy method, and on update nights the full-system backup waits for the updates.
+**Decisions I took on my own: none.** One small deviation from your brief: the Hungarian mail line ends "nincs teendőd", not "teendője nincs", because the product speaks to the household as "te" everywhere.
 
-**The bake-off.** Both ways of keeping the last-second copy passed every test on three apps. Copying the app's data folders won, because one of the apps has no database server and so gets no database copy at all. The extra downtime was 1 to 5 seconds.
+**What the household gets now.** When an update fails and the machine puts the app back, the household gets one mail: "docmost: the update did not work; the app runs on its previous version". When the undo fails too, they get one mail that says the app is stopped and needs a restore, and which backup to use. The mail is in the household's own language. The operator gets the same two events. Two apps on the same night give two mails, not one.
 
-**What the machine does now.** When an update fails its health check, the machine puts back the previous version and the data exactly as it was seconds before the update. It stops the app only if that undo fails too, and then it says so. It never touches the household's own folders (photos, documents).
+**Proven on real machines, through the same buttons the page uses:**
+- On the demo-hp machine: 4 mails to the household and 4 to the operator, first in Hungarian, then in English after one language switch. All arrived. The hub log shows all 8 as sent.
+- On the scratch machine: the update messages on both app pages show in Hungarian and English. A machine with no hub now writes one warning line per kind of lost message.
+- At start, the new version stores the health-check file of each up-to-date app, so its first undo asks the right question. It did this for 3 apps on one machine and 10 on the other.
+- The floor is 0.264.0. The N100 demo machine updated itself within 20 seconds.
 
-**Proven on the scratch machine, through the same buttons the page uses:**
-- Three apps undone by the machine. Data written before the backup, after it, and seconds before the update all came back. It took 30 to 52 seconds.
-- The app page shows one line in Hungarian or English: the update failed, the machine put the app back, nothing was lost.
-- A damaged copy is caught before anything is poured back, and the app is held with an honest sentence.
-- A power cut in the middle of the undo: after restart, the machine finished the undo.
-- A person pressed Update again after the catalogue was fixed, and it worked.
+**What was not clean.**
+- My test "back up now" button backs up the whole machine. On demo-hp it stopped and restarted 9 of the 10 standing apps for a few seconds, twice. All came back healthy, with unchanged files. So "standing apps untouched" is not fully true. I filed a row to fix the test method.
+- Three small leftovers, filed as one row: a reader who forces the other language sees a stopped app's sentence in the machine's language; the raw detail line of an English mail has one Hungarian phrase; and two of my log lines use unclear words.
 
-**What went wrong on my side.** My first build failed its own live test twice. Both times the app stayed stopped with an honest sentence, and the data was safe. The first fault: the machine never asked the old version the right health question. The second: it kept the wrong copy of that question. My unit tests had passed both times. I fixed both the same afternoon and proved the fixes. The released version is the third build.
+**Rows.** Three closed, two new. The list went from 335 to 334.
 
-**Rows.** Four closed, two narrowed, one new. The list went from 337 to 335.
+**What needs you: nothing.** If you do nothing, the fleet keeps the new version. The leftovers are small and wait for a free evening.
 
-**What needs you — one question.** Should the demo machines and the fleet get this version now?
-- **Yes (my pick):** I raise the floor, and both demo machines update themselves within a minute. A failed update then puts the app back instead of stopping it.
-- **Not yet:** nothing changes. A failed update keeps stopping the app until someone restores it.
-
-**Nothing on your own machine, Peti's machine or the off-site box was touched. The demo machines were not touched. The scratch machine runs the new version and is back on the real catalogue.**
+**Nothing on your own machine, Peti's machine or the off-site box was touched, except the hub update. The test apps are gone from both demo machines. Both are back on the real catalogue.**