4c31536909
gates / gates (push) Successful in 25s
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
records-carried — 2026-09-27 (controller v0.276.0): a restore and a drive move keep the app's records
Architecture read before any claim: 07-backup-architecture.md §6.6 (now with "What a restore keeps"), 09 §6.4 part 10
(the conversion copy). Rows: R-697 (closed), R-700 (new; fixed, live proof open), R-691 (2) (not built — why in the row).
Found
- R-697 (known):
PersistUnitRedeployConfigbuilt a freshAppConfig, so a restore droppedconversion_copy— the kept 16 datadir volume was never released. Also dropped:desired_state(a dead app after a restore then reads as "unknown intent" and is not alarmed),failed_update_step,last_update_undone,last_auto_update. - Second orphan (same row): after a restore to the OLD major the ladder converts again;
recordConversionCopyoverwrote the first copy's record with the second's. - R-700 (new, by reading, not seen on a box):
doFlipRedeploy(drive move) persisted through the same fresh write, so it ALSO droppedpinned_images.sync.renderSource: deployed + unpinned → the catalog copied verbatim → the nextupruns the catalog's newest version. Pin adoption runs only at controller start.
Fixed (v0.276.0, controller 820e8ef)
carryLifeRecords in the restore write; earlier_conversion_copies + a release loop over every kept copy;
persistDriveFlip (load-then-save, HDD_PATH only) + upFromAppConfig.
Red-proofs (redproofs/, each seen failing, tree restored, suite green after)
| pre-fix shape | failed at | |
|---|---|---|
| RP1 | no carry in the restore write | conversion_copy = <nil> |
| RP2 | a newer record overwrites the older | earlier [] |
| RP3 | the drive move persists through the restore write | pinned_images = map[] |
| RP4 | doFlipRedeploy back on RedeployFromEnv |
the wiring test |
Live (endpoint level + guest reads)
R/R1-9202-0.276.0.txt— 9202 by hand, healthy.R/R2-floor.txt— global floor 0.276.0 (MinAgent 0.131.0), both demo boxes on 0.276.0 within 10 s, healthy.R/R3-9202-paperless-record.txt— after the upgrade paperless-ngx keepsconversion_copy(16 → 18, at 09:45:15Z) and its.pre-update-20260927T094421Zvolume; the release job registered.- Night (N/): the release on a real 18 dump — see
N/README.mdonce written.
Not proven live
- R-700: no Tier-0 guest has two drives (9202 has one:
scratch_hdd). Unit-proven only; row stays WATCHING. - R-697's carry across a real restore: restoring paperless now would bring it back at 16 (its unit's data is the pre-conversion dump) and would spoil the night's release proof. Unit-proven only.
Teardown: provisioned nothing. Machine: 9202 controller image changed 0.275.0 → 0.276.0 (kept). Host: nothing. Hub: global floor 0.275.0 → 0.276.0.