admin
05ea21e918
- 09 §6.1 phase table (copying, undoing, undone), §6.1a SHIPPED with the two live-only defects, §6.4 part 1 SHIPPED. - Capability map: a failed update is undone by the box - PROVEN-LIVE. - Live evidence on 9202: three apps undone by the product with seeds before the backup, after it and seconds before the press read back; cut-off copy held honestly; power cut during the undo resumed; manual press after undo. - Register: R-637, R-639, R-641, R-642 closed; R-638, R-640 narrowed; R-643 ruled; R-646 opened. STATUS asks the floor question. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2.6 KiB
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.
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.
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 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 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 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. Four closed, two narrowed, one new. The list went from 337 to 335.
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.