R-812 option A (hub): the Proxmox package set — candidate, operator approval, System page

Layer pve: never auto-approved; the candidate is the Proxmox userspace set
every ring-0 box reports (kernel / boot / firmware names left out); the
operator's "Approve Proxmox set" button appears only after 2 healthy night
pve steps on every ring-0 box; an approval nudges no box (ring 1 by a signed
os_pve_step). 11 §5.10 written (BUILT, unreleased, not yet proven live); §8
step 6 split (userspace §5.10, kernel R-836).

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

documentation/architecture/11-os-updates.md

@@ -469,6 +469,38 @@ Decision 88 (R-851): *"Yes, but maybe not indefinitely."* Evidence `audits/os-do
 
 ---
 
+### 5.10 The Proxmox package lane — BUILT 2026-10-07, unreleased, not yet proven live (R-812 option A, `09` §3 decision 163)  `[FACT]`
+
+**What it updates:** the host's Proxmox USERSPACE packages (pve-manager, qemu-server, pve-container, lxc-pve,
+libpve-*, proxmox-widget-toolkit, the ceph client libraries …) — the 77–78 packages behind on the demo boxes on
+2026-10-07. **What it never touches:** a kernel, boot, firmware or microcode name (`HOST_SLOW_RE`: `proxmox-kernel*`,
+`proxmox-default-kernel`, `pve-kernel*`, `pve-firmware`, `shim*`, `grub*`, `systemd-boot`, `*-microcode`, `efibootmgr`)
+— that is R-836's lane (decision 164). No reboot.
+
+- **Wrapper** (`felhom-agent/configs/felhom-os-apply`): layer `pve`, lane `slow` only. Origin `Proxmox Debian
+  Repository` only (R2; a Debian package in a pve plan or simulation is refused); R14 on every name in the plan and the
+  simulation; no removal (R4); no undo (R5 — put a version back by hand); a NEW package only from `PVE_NEW_ALLOW`
+  (`proxmox-firewall-data`, the one new userspace package a full upgrade adds on demo-felhom); an appliance only (R12);
+  authority R3 — a signed `os_pve_step` (op bound to the exact package list, host, time window, nonce) or the root-owned
+  ring-0 mark (`ring0_slow_lane`). Ring 0 selects `pending-pve`: every installed Proxmox-origin package with a pending
+  upgrade. The report carries `pve_manager` (pveversion after the step). Tests: `PVELane` (17).
+- **Agent** (`internal/osupdate`): ring 0 runs it in the night leg AFTER a healthy host step (an appliance; a Docker
+  step's outcome does not gate it); ring 1 never in the night leg — only a signed `os_pve_step` (`PVEStepExecutor`, under
+  the heavy-op gate). Health (`PVEHealthVerdict`) = the host rule (§8.2) + every running container keeps its id (the
+  household's apps were not restarted) + pveversion reads the pve-manager the step installed.
+- **pmxcfs** (`internal/pvegate`): pve-cluster's postinst restarts pmxcfs (the filesystem behind /etc/pve). While a pve
+  step runs, the agent's own /etc/pve writes WAIT — every non-GET Proxmox API call (`Client.doBody`) and every root CLI
+  that writes /etc/pve (`ExecRunner.RunStdin`: pct config verbs, pvesm, pveum, felhom-pbs-apply create/reconcile). The
+  step first waits for writes in flight; after 2 minutes it gives up and does not run (`failed`). Backups and
+  restore-tests are already out (the heavy-op gate).
+- **Hub** (`osupdates`): layer `pve` — never auto-approved. The candidate is the Proxmox userspace set every ring-0 box
+  agrees on (kernel names left out). The operator's **„Approve Proxmox set"** button on the System page appears only
+  when every ring-0 box ran the set in `DockerNightsEffective` (2) healthy night steps since it was first seen and none
+  was unhealthy — „healthy" is the box's own verdict above (no memory-kill check; that is the Docker engine's, R-528).
+  An approval nudges no box: ring 1 takes the set only by a signed `os_pve_step` (signed per box, as `os_docker_step`).
+- **Not yet:** the live proof on demo-felhom (ring 0); the undo runbook (by hand: `apt-get install <name>=<old>` —
+  Proxmox keeps 30–66 old versions, C2).
+
 ## 6. Risks and edge cases
 
 | # | What can go wrong | What the design does |
@@ -547,7 +579,8 @@ Each step returns to the operator for go or no-go.
    not needed:** measured on Tester 2, the agent's first OS leg ran right after the box's FIRST whole-guest backup, 17 min
    after enrolment (16:24/16:25 UTC: 49 guest + 106 host packages, 110 s + 44 s, healthy). An installer pass would cost
    ~45 s and run BEFORE any whole-guest backup exists (no undo) — not built.
-6. **Slow lane: host kernel and Proxmox packages, with the reboot.**
+6. **Slow lane: host kernel and Proxmox packages, with the reboot.** **Split 2026-10-07 (decisions 163–164):** the Proxmox
+   USERSPACE packages are §5.10 (BUILT, unreleased, no reboot); the kernel lane is R-836 (a spike with reboots first).
 7. **Later:** the Proxmox major upgrade (PVE 9 → 10), drilled on ring 0 first.
 
 ---