Clarify Proxmox LXC Docker install path

docs/release-control/v6/internal/subsystems/agent-lifecycle.md

@@ -779,7 +779,7 @@ profile and assignment columns, but embedded table framing must route through
 7. Add or change the unified agent CLI entrypoint, version/help exit semantics, or startup argument/error routing through `cmd/pulse-agent/main.go`.
    The CLI entrypoint owns propagation of persistence context into runtime-owned helpers. When installer-selected state roots differ from the default, `cmd/pulse-agent/main.go` must pass that exact `StateDir` through both the host-agent runtime and updater startup paths instead of letting one path silently fall back to `/var/lib/pulse-agent`.
    The same runtime-owned boundary also owns Pulse control-plane URL validation for agent startup, remote config, updater continuity, and command transport. Non-loopback control-plane URLs remain HTTPS/WSS by default, but explicitly insecure agent/dev-runtime flows may use plain HTTP/WS for LAN development control planes; installer-persisted dev URLs must not be accepted by one runtime path and rejected by another.
-   The unified agent CLI copy follows the same Patrol remediation vocabulary as the install surface. `cmd/pulse-agent/main.go` may keep the `--enable-commands` flag name for compatibility, but the help text and inline comments must describe command execution as Patrol remediation rather than reviving AI auto-fix language.
+   The unified agent CLI copy follows the same command-execution vocabulary as the install surface. `cmd/pulse-agent/main.go` may keep the `--enable-commands` flag name for compatibility, but the help text and inline comments must describe command execution as Pulse command execution for Patrol actions and governed Proxmox LXC Docker inventory rather than reviving AI auto-fix language.
    The unified agent CLI copy also owns operator-facing Docker / Podman runtime
    labels. `cmd/pulse-agent/main.go` may keep the historical
    `--enable-docker` and `--docker-runtime` flag names for compatibility, but
@@ -3061,6 +3061,12 @@ install copy may recommend installing the agent on every machine that needs
 temperatures, SMART disk data, services, Docker, or Kubernetes telemetry, but
 they may not imply that API-backed cluster visibility or best-effort peer
 augmentation is equivalent to a local agent install on that machine.
+Docker onboarding copy must also distinguish the standalone Docker / Podman
+install path from Docker inside Proxmox LXCs: standalone runtimes use the
+Docker runtime profile on that host, while Proxmox LXC Docker inventory uses a
+Proxmox VE node agent with command execution plus explicit server-side
+`PULSE_ENABLE_PROXMOX_GUEST_DOCKER_INVENTORY=true`, and the copy may not imply
+that installing an agent inside every LXC is required.
 That same connected-systems summary must preserve canonical local operator
 identity for newly connected infrastructure. When governed resources such as
 PBS or PMG appear in the setup-completion poll, the surface must show their

docs/release-control/v6/internal/subsystems/api-contracts.md

@@ -378,6 +378,11 @@ payload shape change when the portal presents compact client rows.
     `frontend-modern/src/utils/sourcePlatforms.ts` rather than page-local
     wording, because those install choices set API-token and install-command
     expectations for the operator.
+    That same install-profile model must keep the standalone Docker / Podman
+    runtime profile distinct from Proxmox LXC Docker inventory. The Docker
+    profile may force local runtime monitoring, while Docker inside LXCs must
+    point operators to the Proxmox VE node profile plus command execution and
+    explicit server-side guest Docker inventory opt-in.
     That same browser/API boundary must not retain customer-side commercial or
     onboarding telemetry wrappers around infrastructure operations. Pulse
     Account and the server-owned commercial reporting routes own commercial
@@ -1178,6 +1183,11 @@ the canonical monitored-system blocked payload.
     rewritten into source credential, liveness, or setup failure facts.
     That same governed infrastructure-operations API boundary also owns discovery polling activation: the shared discovery runtime may only poll `/api/discover` while the settings shell has the `infrastructure-connections` route active, so route-level IA changes cannot silently keep discovery traffic alive on unrelated systems or install screens.
     That same governed setup/install boundary also owns uninstall convergence: when a script-managed Proxmox node removes its local Pulse credentials, the canonical `/api/auto-unregister` API must remove the matching stored node immediately and emit the same discovery/node-deleted refresh semantics as manual deletion, so the infrastructure sources table does not keep a stale active row until the next failed poll.
+    That same governed install-presentation boundary must preserve the
+    Docker-versus-Proxmox LXC distinction from the shared model: generated
+    install surfaces may not imply that Docker inside Proxmox LXCs requires a
+    guest-local agent when the intended path is a Proxmox node agent with
+    command execution and server-side guest Docker inventory opt-in.
     That same governed setup/install boundary also owns Proxmox
     `authorized_keys` symlink preservation in the rendered PVE setup script:
     temperature-key install and uninstall edits must resolve the real

docs/release-control/v6/internal/subsystems/deployment-installability.md

@@ -271,6 +271,12 @@ TLS floor in the dynamic config.
    settings, insecure flag, and persisted agent id from the local installed
    agent state, must fail closed when no existing installation or connection
    state is present, and must refuse to silently become a new install command.
+   The shell installer must disclose `--enable-commands` as Pulse command
+   execution, disabled by default, and must name both Patrol actions and
+   Proxmox LXC Docker inventory as the operator-visible reasons to enable it.
+   When enabled, the terminal summary must also state that Proxmox LXC Docker
+   inventory still requires explicit server-side
+   `PULSE_ENABLE_PROXMOX_GUEST_DOCKER_INVENTORY=true`.
 
 ## Extension Points
 
@@ -314,6 +320,10 @@ TLS floor in the dynamic config.
    installer in that slot silently breaks every one of those flows because the
    agent installer rejects `--version` as an unknown argument; this drift
    shipped across v6 rc.1 → rc.5 (April 12 → May 11, 2026) before being caught.
+   Installer-facing command-execution copy must remain aligned with the served
+   agent installer: Proxmox LXC Docker inventory may be described only as an
+   opt-in host-side path that requires both agent command execution and server
+   guest-Docker inventory opt-in.
    `scripts/validate-release.sh` must therefore fail the release if the
    published `install.sh` does not carry the server-installer banner, does not
    handle `--version)` in its argument parser, contains the agent installer

docs/release-control/v6/internal/subsystems/frontend-primitives.md

@@ -269,6 +269,11 @@ bounds, current/desired replicas, and metric source columns.
 Kubernetes events inventory follows that same primitive boundary while the
 unified-resource owner supplies Event type, reason, involved-object, count,
 observed-time, and message columns.
+Docker empty-state guidance on platform pages follows the same shared platform
+primitive boundary: it may use the route-specific Docker / Podman vocabulary,
+but it must distinguish standalone Docker host installation from the Proxmox
+LXC Docker host-side inventory path without adding page-local installer command
+assembly or token handling.
 Docker / Podman inventory follows that same primitive boundary while the
 unified-resource owner supplies API-object-specific container, image, volume,
 network, Swarm node, task, secret, and config columns through dedicated native

docs/release-control/v6/internal/subsystems/security-privacy.md

@@ -157,7 +157,7 @@ controls as normal product settings.
    auth-env reloads, hosted entitlement refresh origins, and
    pinned-fingerprint TLS clients keep one fail-closed security floor.
 9. Change operator-facing Resource Privacy/Data Handling posture through `frontend-modern/src/components/Settings/DataHandlingPanel.tsx` and `frontend-modern/src/components/Settings/dataHandlingPanelModel.ts` together so resource classification, handling-boundary, redaction copy, and the route-backed/hidden-sidebar presentation stay governed as a trust surface.
-10. Change inside-guest runtime collection boundaries through `docs/AGENT_SECURITY.md`, `docs/UNIFIED_AGENT.md`, `cmd/pulse-agent/main.go`, `internal/api/router.go`, and `internal/config/config.go` together. Docker / Podman inventory inside a VM or LXC may come from a guest-local `pulse-agent` module or explicitly reported guest data; LXC Docker inventory may also be collected by a Proxmox host agent only through explicit server opt-in, with optional VMID allowlisting and a minimal summary command set that avoids `docker inspect`, environment, mount, file, command, and process collection. Local Unified Agent Docker / Podman disables must not be reversed by remote profile configuration, and self-test/update preflight that needs the live runtime token must pass it through a short-lived token file rather than argv. The `--enable-docker` help line is part of that operator privacy control, so it must remain "Enable Docker / Podman Agent module" instead of exposing internal collection-module wording.
+10. Change inside-guest runtime collection boundaries through `docs/AGENT_SECURITY.md`, `docs/UNIFIED_AGENT.md`, `cmd/pulse-agent/main.go`, `internal/api/router.go`, and `internal/config/config.go` together. Docker / Podman inventory inside a VM or LXC may come from a guest-local `pulse-agent` module or explicitly reported guest data; LXC Docker inventory may also be collected by a Proxmox host agent only through explicit server opt-in, with optional VMID allowlisting and a minimal summary command set that avoids `docker inspect`, environment, mount, file, command, and process collection. Local Unified Agent Docker / Podman disables must not be reversed by remote profile configuration, and self-test/update preflight that needs the live runtime token must pass it through a short-lived token file rather than argv. The `--enable-docker` help line is part of that operator privacy control, so it must remain "Enable Docker / Podman Agent module" instead of exposing internal collection-module wording. The `--enable-commands` help line and installer disclosure must identify Pulse command execution as disabled by default and required for Patrol actions or the explicit Proxmox LXC Docker inventory path, not as implicit guest access.
     Global resource timeline reads through `/api/resources/timeline` are
     adjacent monitoring-read surfaces, not a privacy bypass. Provider activity
     filters may expose backend-authored task/event metadata, but the endpoint

docs/release-control/v6/internal/subsystems/unified-resources.md

@@ -170,6 +170,11 @@ evidence, and inactive standalone Swarm metadata must not be interpreted as
 host-role or service-surface proof. The unified-resource adapter is the backend
 fail-closed layer for that rule, so persisted or older-agent inactive Swarm
 payloads cannot reintroduce false Swarm capability surfaces.
+The empty state for this route must preserve that runtime-lens contract:
+standalone Docker / Podman hosts use a local runtime agent, while Docker inside
+Proxmox LXCs is represented as the explicitly opted-in Proxmox host-side guest
+Docker inventory path rather than a requirement to install an agent in every
+guest.
 
 Platform Overview tabs are rollup boundaries, not duplicate inventory dumps.
 Docker / Podman Overview owns runtime host rows and primary container workload