# `mgf-vm-libvirt` — scope policy

## §1 In scope (SP-01)
- a libvirt/KVM/QEMU **adapter** implementing mgf-vm-core's `HypervisorBackend` + `StorageBackend`
- the libvirt connection, domain-XML generation/parsing, storage/network/metrics/guest-agent backends,
  the libvirt event pump, and libvirt→mgf-vm-core typed error translation

The boundary: **drive real KVM/QEMU via libvirt, behind mgf-vm-core's Protocols.**

## §2 Out of scope (SP-02)
| Not here | Why | Where instead |
|---|---|---|
| The VM domain model / state machine | owned upstream | `mgf-vm-core` |
| Firecracker / other engines | a different adapter | `mgf-vm-firecracker` |
| The client SDK / control plane | sits above adapters | `mgf-vm-sdk` / `vm-vmanager-app` |
| A CLI/GUI | adapter library | the apps |
| OVA/OVF interchange | separate concern | `mgf-vm-interchange` |

## §3 Scope-creep gate (SP-03)
A PR MUST answer: (1) is it libvirt-adapter code implementing the core Protocols (else out)? (2) does
it keep libvirt-python confined here (import-linter) + domain XML escaped (ElementTree, never f-string)
+ all libvirt-output parses through defusedxml? (3) consumer demand? Any "no" blocks it.

## §4 Adjacent scope (SP-04)
Adjacent: live-migration, more device models, a libvirt-secret backend. Promote on a documented demand signal.

## §5 Alternatives for out-of-scope needs (SP-05)
Domain → `mgf-vm-core`; Firecracker → `mgf-vm-firecracker`; SDK → `mgf-vm-sdk`; CLI/GUI → the apps.

## §6 Revisiting scope (SP-06)
Revisited at every **MAJOR** boundary; re-affirms the adapter-only / libvirt-confined / XML-safe invariants.
