Classify Proxmox guest lifecycle transport

This commit is contained in:
pulse-triage[bot] 2026-08-30 01:12:57 +01:00
parent ac2a2fe020
commit b001ad8ef1
5 changed files with 14 additions and 2 deletions

View file

@ -7169,6 +7169,10 @@ typed `docker_container_update` operation with durable receipts and declared
backup/rollback compensation, while the model-originated
`assistant.docker.update` route and the legacy queued update transports stay
`retired_denied`.
Proxmox guest lifecycle dispatch has the same closed pairing:
`transport.agent.proxmox-guest-lifecycle` requires prior durable
`resource.proxmox.guest-lifecycle` authority, while the lifecycle result is
non-admitting evidence and cannot create dispatch authority.
Enterprise command-remediation records are readable historical imports only.
Production code contains no command or rollback execution algorithm; exported

View file

@ -9091,8 +9091,12 @@ CRUD are not claimed as customer-infrastructure mutation enumeration.
Raw command/file write/arbitrary pod exec, the legacy queued Docker
update/control transports, and enterprise command remediation are retired
compatibility surfaces. Container image updates re-entered the plane as
`resource.docker.container-update` and
compatibility surfaces. Proxmox guest lifecycle uses the paired
`resource.proxmox.guest-lifecycle` and
`transport.agent.proxmox-guest-lifecycle` authorities: the typed transport can
dispatch only after the durable non-transport lifecycle record exists, and its
result message is non-admitting evidence. Container image updates re-entered
the plane as `resource.docker.container-update` and
`transport.agent.docker-container-update`: lifecycle-dispositioned, planned
against an `update` capability that containers advertise only while an image
update is detected, and executed solely through `dockerContainerActionExecutor`