menu update

README.md

@@ -29,7 +29,7 @@ On their first launch after receiving this version, control is handed to the
 current preloader so the new startup configuration and registration procedures
 run before the menu opens.
 
-The TA-ProxMenu Management menu can safely switch TA-ProxMenu between branches published on
+The TAPM Management menu can safely switch TA-ProxMenu between branches published on
 its Git origin. Branch switching is refused when the installed repository has
 local changes or when the destination branch has commits that would be
 discarded.
@@ -49,6 +49,71 @@ The shared menu layout and disk report omit ANSI styling when redirected or when
 findings by storage and node, and explain approximate sizes without adding CSV
 columns. CSV content and disk classification are unchanged by the presentation.
 
+## Menu organization
+
+- **Host Configuration & Recovery**: TAPM host profile and local Proxmox service recovery.
+- **Monitoring & Agents**: Pulse, Glances, supported legacy Dell OMSA, RMM,
+  Acronis, SentinelOne, ScreenConnect, and Proxmox notifications.
+- **Cluster & High Availability**: host maintenance, cluster VM CPU baseline,
+  and the Keepalived floating IP.
+- **Storage, ISOs & Backups**: shared ISO storage, Windows VirtIO driver ISOs,
+  orphan/unused disk reporting, and local Proxmox backup bandwidth/I/O priority.
+- **TAPM Management**: TAPM updates, Git branch selection, and installation information.
+
+Existing direct actions remain compatible. Installed agent entries still run
+installers; they do not launch the corresponding application. Host configuration
+backups are explicitly identified to distinguish them from guest backups.
+
+## Proxmox notifications
+
+Open **Monitoring & Agents → Proxmox Notifications → Update notification policy**:
+
+- **All available package updates**: use Proxmox's native daily update alerts,
+  regardless of subscription status, through the existing notification routing.
+- **Proxmox VE version updates only**: notify when a newer Proxmox VE version,
+  including a patch release, is available from a host's configured repositories.
+- **Disable update notifications**: suppress native daily update alerts.
+
+The policy applies to the Proxmox datacenter, including all cluster nodes.
+Selecting a policy displays its scope and requires confirmation before applying.
+Other notification types and destination credentials are preserved. Normal
+Proxmox repository checks remain enabled; this feature never upgrades packages
+or sends an alert confirming that a host was upgraded.
+
+Version-only mode installs an hourly systemd timer on the host where the policy
+is applied. This host checks online cluster nodes through the Proxmox API;
+standalone hosts check themselves. Repository indexes are refreshed by Proxmox's
+existing daily update job, not by the TAPM checker. Kernel-only and other package
+updates do not trigger version-only alerts. Checks pause while the checker host
+is offline. Reapply the version-only policy on another host to move the checker;
+old checkers consult the shared policy and stop sending automatically. Newly
+joined nodes are discovered at the next check.
+
+Version alerts include the hostname, installed version, and available version.
+They use the existing system-update routing rules and destinations. Configure
+recipients and delivery credentials in **Datacenter → Notifications** in the
+Proxmox Web UI. TAPM can display the destinations/rules and explicitly send a
+chosen destination a test notification. Testing a destination does not test its
+routing rules; ensure those rules allow informational system-update events.
+
+The checker records announced versions per node in the private cluster
+configuration, so moving the checker preserves its history. Failed sends are
+retried on subsequent checks. Submission to the notification subsystem is not
+confirmation of delivery; the configured destination and routing must work.
+Offline nodes and failed reads are logged and retried without stopping checks
+for other nodes. No notification policy is changed merely by installing or
+opening TAPM.
+
+Operational files:
+
+- `/etc/pve/priv/tapm-update-policy.json`: shared policy and checker host.
+- `/etc/pve/priv/tapm-update-policy.previous.json`: previous policy and native
+  notification options, saved before each change for manual recovery.
+- `/etc/pve/priv/tapm-update-receipts.json`: announced versions per host.
+- `/etc/pve/notification-templates/default/tapm-pve-version-*.hbs`: version alert templates.
+- `tapm-version-notifications.timer` and `.service`: checker scheduling; inspect
+  results with `journalctl -u tapm-version-notifications.service`.
+
 ## Direct actions
 
 The menu script also supports these direct actions:
@@ -74,7 +139,7 @@ orphan-disks Report cluster-wide orphan candidates and unused disks (read-only)
 
 ## Orphaned and unused disks
 
-Open **Cluster & Maintenance → Find orphaned and unused disks [Read-only]**.
+Open **Storage, ISOs & Backups → Report orphan candidates and unused disks (read-only)**.
 The menu offers CSV export after displaying the report. Direct commands:
 
 ```bash
@@ -224,7 +289,7 @@ Later launches make one best-effort HTTPS call on completion or failure to
 record the hostname, duration, result, TA-ProxMenu and Git versions,
 PVE/OS/kernel versions, architecture, and whether the host is clustered. A
 failed event schedules re-enrollment on the next invocation instead of adding
-another retry to the current run. No background service is installed, and
+another retry to the current run. The installation registry does not install a background service, and
 broker availability never prevents the menu from running.
 
 Automatic Git update checks and the stable VirtIO release lookup are cached for