felhom.eu/documentation/audits/undo-live-2026-09-23

The undo, live on 9202 — controller v0.263.0 → v0.263.2, 2026-09-23

Venue: scratch guest 9202 (demo-hp), drill catalog (admin/app-catalog-drill, reset to live cfcfe5278428 before and after), update.health_timeout: 90s. Method: endpoint-level — every act is the endpoint the UI invokes (deploy, backup, sync, rescan, update, start, remove, the language switch) and every page is fetched as HTML (/apps/<app>?lang=hu|en); no browser. The product performs the undo; nothing here does. Each edge is a real migrating image move with, in the DRILL template only, a health probe on a port the app does not answer. Seed A before the backup, seed B after it, seed C seconds before the press — C exists only in the undo's own last-second copy.

Not done, or changed

• Three releases, not one. v0.263.0 was built, deployed to 9202 only, and its first two live proofs FAILED honestly (HELD, data put back, old version judged "did not start"). Two defects the unit tests could not see; each fixed, red-proofed and released the same session: v0.263.1 (the undo's probe was gated on running while the current probe held the app unhealthy) and v0.263.2 (the "old" .felhom.yml saved at update time was already the new one — it flows in on every catalog sync). Only 9202 ever ran 0.263.0/0.263.1; both images were removed from it by name. No floor was raised.
• The mail and the operator event of decision 15 are not built (09 §6.4 part 2).
• The hold sentence body stays Hungarian on an English box (R-606); only the new prefix follows the box language.

Results (all on v0.263.2 unless stated)

proof	result	evidence
docmost (PostgreSQL) undone by the product	failed probe at +107 s → undoing → undone at +137.6 s; A, B, C read back; 42 tables, 48 ledger before and after; 0 copies left	40-undo-docmost.txt
romm (MariaDB)	undone at +163.9 s (undo 52 s); A, B, C; 24 tables, alembic 0095 before and after	40-undo-romm.txt
vikunja (SQLite in a volume)	undone at +97.1 s (undo 3 s); A, B, C; 36 tables, ledger 117 before and after	40-undo-vikunja.txt
the page line, both languages	hu: „A(z) docmost frissítése 2026-09-23 12:05-kor nem sikerült. A doboz automatikusan visszaállította az előző változatot és az adatokat — semmi nem veszett el." · en: "The update of docmost at 2026-09-23 12:05 did not succeed. The box put back the previous version and its data automatically — nothing was lost." (same for romm, vikunja)	40-undo-*.txt
a cut-off copy (vikunja: the finished-marker taken from one copy during verifying)	undoing → failed in 0.6 s, nothing poured back; hold (hu box): „A frissítés nem sikerült, és az automatikus visszaállítás sem. Az adatok az új változat által hagyott állapotban vannak. A(z) vikunja frissítése …"; en box: "The update did not succeed, and the automatic undo did not either. The data is as the new version left it. A(z) vikunja …"; both copies kept	60-cutoff-vikunja.txt
a power cut during the undo (romm: pct stop 9202 the moment the phase read undoing)	after boot: update recovery: romm was interrupted while UNDOING … RESUMING the undo → undone; A, B, C; ledger equal; 0 copies left	50-powercut-romm.txt
a person presses Update after an undo (docmost; the drill catalog then fixed the probe)	done at +36.8 s on 0.96.0; A, B, C; the undone line gone from both pages; last_update_undone gone from app.yaml	70-manual-press-docmost.txt
a failed undo holds honestly (v0.263.0, docmost and romm — the defect above)	HOLD „… Az adatok a frissítés előtti állapotba kerültek vissza, de az előző változat nem indult el." — true: the data had been put back; the old version was never probed	10-docmost-undo.txt, 20-romm-undo.txt
removal deletes kept copies (vikunja, held with 2 copies)	2 → 0 after POST /api/stacks/vikunja/remove	95-teardown.txt
R-642, the Start answer	Stack romm start requested — state now: running	80-r642-start-answer.txt

Extra downtime of the copy (the app is stopped there anyway to be recreated): the copying phase lasted 2.1 s (docmost), 6.8 s (romm, incl. a 3.8 s stop), 1.6 s (vikunja).

Teardown — three layers

• machine (9202): docmost, romm, vikunja removed through the product (no containers, no volumes, no undo copies); romm's drive folder removed by name (the product kept it, R-442 as in every drill); test images removed by name (docmost 0.95.0/0.96.0, romm 5.0.0/5.3.0, vikunja 2.3.0/2.6.0, nextcloud 34.0.1-apache, controller 0.263.0/0.263.1); controller.yaml restored from the saved copy and read back identical; catalog cache re-cloned from the live repo (cfcfe52). 9202 stays on controller 0.263.2 (self-update off; the fleet floor is untouched at 0.262.1). Apps afterwards: the same three as at the start of the day (gokapi still crash-looping, R-644).
• host (demo-hp): nothing provisioned; the guest was stopped and started once for the power cut.
• hub: nothing touched.
• drill repo: reset to live main, image lines identical, has_actions: false.