Problem
The deployment teardown path imports the VMID safety guard but never calls it — it's a no-op placeholder.
Evidence
app/routes/v1/deployments/teardown.py:68 — _ = filter_safe_vmids # retained for later wiring
Impact (High)
The only thing preventing teardown from destroying protected VMIDs (e.g. 100/101 / canonical ranges) is the Ansible teardown playbook. There is no API-layer guard. If the playbook is wrong/absent or a manifest is malformed, teardown can target protected guests.
Suggested fix
Wire filter_safe_vmids() against the deployment's resolved VMID list before dispatching teardown; refuse (or exclude + warn) protected VMIDs, mirroring the _assert_vmid_safe guard used on snapshot rollback / vm delete.
Problem
The deployment teardown path imports the VMID safety guard but never calls it — it's a no-op placeholder.
Evidence
app/routes/v1/deployments/teardown.py:68—_ = filter_safe_vmids # retained for later wiringImpact (High)
The only thing preventing teardown from destroying protected VMIDs (e.g. 100/101 / canonical ranges) is the Ansible teardown playbook. There is no API-layer guard. If the playbook is wrong/absent or a manifest is malformed, teardown can target protected guests.
Suggested fix
Wire
filter_safe_vmids()against the deployment's resolved VMID list before dispatching teardown; refuse (or exclude + warn) protected VMIDs, mirroring the_assert_vmid_safeguard used on snapshot rollback / vm delete.