mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-10 18:45:53 +00:00
rcourtman
7996848b64
A paying operator asked the Assistant to reboot five Proxmox VMs matching a name pattern (GitHub #1782, support mail 2026-08-26 and 2026-08-29). The model resolved the VMs and then ended with a report that invented a prerequisite: a QEMU guest agent on 6.3.2, a "discovery binding" on stable 6.4.0. It never planned the action. Three defects made the governed path fail whenever the model did try it, and nothing refused the prose ending when it did not: - pulse_control handed the session-scoped id (vm:<node>:<vmid>) to the action lifecycle, whose registry keys on canonical unified ids, so a Proxmox guest plan could never resolve. - pulse_control gated the action on the legacy per-executor action list, which never carried the canonical "reboot" capability Proxmox guests advertise, so "reboot" was refused as not permitted before planning. - A reference absent from the session context was refused with "resource discovery is required" even when the unified inventory resolved it. pulse_control now binds its target to the canonical unified resource (session alias first, then a unique inventory match, refusing ambiguity with candidate ids and naming the pulse_query recovery on a miss), passes the canonical id to the planner, and answers "not available" only from the resource's current advertised capabilities. The FSM ordering block and the shared operating instructions state that a recoverable block is not a limitation to report, and the instructions require the governed action tool for advertised capabilities. The agentic loop adds a bounded advertised-action gate: when the operator asked for a lifecycle action, pulse_control was offered but never submitted, and a session-resolved resource advertises the action, a tool-free final answer is refused once with the exact per-target calls. Covered by tools and loop unit tests (the #1782 transcript against a scripted provider fails on the previous code with the two exact errors above), a prompt-contract test, and the live eval scenario ProxmoxBulkLifecycleActionScenario.