# `mgf-vm-firecracker` — scope policy

> Scope policy (family **SP**) — what belongs in the Firecracker adapter.

## §1 In scope (SP-01)
- a Firecracker/jailer **adapter** implementing mgf-vm-core's `HypervisorBackend` + `StorageBackend`
- the Firecracker REST client (httpx over the unix socket), jailer launch, VmSpec→Firecracker translation, error translation to mgf-vm-core's typed tree

The boundary: **drive Firecracker microVMs behind mgf-vm-core's Protocols.**

## §2 Out of scope (SP-02) — with reasons
| Not here | Why | Where instead |
|---|---|---|
| The VM domain model / state machine | owned upstream | `mgf-vm-core` |
| libvirt/QEMU engines | a different adapter | `mgf-vm-libvirt` |
| The client SDK / control plane | sits above adapters | `mgf-vm-sdk` / `vm-vmanager-app` |
| A CLI/GUI | adapter library | the apps |

## §3 Scope-creep gate (SP-03)
A PR MUST answer: (1) is it Firecracker-adapter code implementing the core Protocols (else out)?
(2) does it keep httpx/Firecracker isolated to this adapter (import-linter)? (3) consumer demand?
Any "no/unclear" blocks it.

## §4 Adjacent scope (SP-04)
Adjacent: a Firecracker snapshot/restore extension, a vsock guest-agent transport. Promote on a
documented consumer-demand signal only.

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

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