hub v0.142.0: R-812 A, R-32, R-366 slice 2, R-105
gates / gates (push) Successful in 2m44s

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
This commit is contained in:
2026-10-07 13:10:21 +02:00
parent c79e475511
commit ed7fff943d
+6 -2
View File
@@ -1,4 +1,8 @@
## Unreleased (2026-10-07) — the Proxmox package set (R-812 option A, `09` §3 decision 163)
## v0.142.0 — the Proxmox package set; RESET purges the off-site folder; one line when old copies use another key; the two never-built DR fields retired (R-812 A, R-32, R-366, R-105; `09` §3 163, 167–169) (2026-10-07)
**Operator action on deploy: none.** Built and deployed in the attended session (decision 162).
### The Proxmox package set (R-812 option A, decision 163)
- hub (osupdates): layer `pve` — the host's Proxmox userspace set. Never auto-approved; the candidate is what every
ring-0 box reports (kernel / boot / firmware names left out); `PVEStatus` / `ApprovePVE`: approvable only after every
@@ -9,7 +13,7 @@
shown only when the rule allows it.
- Tests: `TestPVE_*` (4), `TestSystemPage_PVEButtonOnlyWhenReady`, the R-135 route list. Red-proofs:
`documentation/audits/day-2026-10-07/B/red-hub-pve-mutations.txt`.
## Unreleased (2026-10-07)
### RESET, the other-key line, the retired fields (R-32, R-366, R-105)
- hub (R-366 slice 2, `09` §3 decision 168): the host report's new `foreign_key_archives` (per tier: the count and date range of whole-guest archives the restore-test skipped as written with another key) becomes ONE `restore_test_foreign_key_archives` info line on the operator's timeline per change of the set — not per archive, not per report; an absent stanza keeps the state, `tiers: []` clears it. Never mailed. `TestR366_ForeignKeyArchivesOneEventPerChange` (red-proved twice, `documentation/audits/day-2026-10-07/E/`). `07` §6 updated.
- hub (R-32 option A, `09` §3 decision 167): RESET's off-site leg on the shared pool box purges the household's folder — the repository and every `<repo>.orphaned-*` copy, nothing else — through the sub-account's OWN login (`offsitekeys.Registrar.PurgeRepos`, the `DeleteSetAside` route) BEFORE it deletes the sub-account; a failed purge or no purge route keeps the sub-account and fails the leg (re-run resumes). It used to delete only the sub-account (a login), leaving the folder for the next lifecycle. The false "repo DATA dies with the sub-account" comment is corrected. Tests `TestDeprovision_R32_*`, `TestPurgeRepos_R32_*` (red-proved, `documentation/audits/day-2026-10-07/D/`). `07` §6 (RESET) updated.