Conformance group: the sandbox lifecycle (012 T032; 003-FR-010, 003-FR-013).

Provision → start → stop → destroy, plus the two cases that are easy to get wrong and cheap to get right:

• concurrent double-provision resolves to one sandbox (003-FR-010). Two requests for the same sandbox id arriving together must not produce two sandboxes; one of them is a leak nothing will ever clean up, because the host records only one.

• a second destroy returns :ok (003-FR-013). Cleanup runs from crash-recovery sweeps, which by their nature run against sandboxes that may already be gone. A destroy that errors on "already gone" makes every sweep a source of spurious failures, and the usual response to that is to stop running the sweep.

The three checks 003 T018–T020 added

012 built this group around the mechanism callbacks. 003 covers the rest of quickstart Scenario 3, and the additions are the steps most easily skipped because none of them is on the happy path:

• step 3 — a missing template fails naming the template (003-FR-027). The distinguishable-cause requirement, at the one point where the generic error is most tempting: provisioning fails for many reasons and they all arrive as {:error, _}.

• step 4 — a mid-provision failure leaves zero orphans (003-SC-006), verified by enumerating list_running/0 rather than by inspecting the cleanup code. SC-006 is a claim about unanticipated failures; a check that trusts the compensation path can only confirm the paths its author thought of, which is the same set the compensation already handles.

• step 5 — data survives a stop/start cycle. A mechanism that reprovisions from the template on start/1 passes every other check in this group: it starts, it reports :running, it appears in list_running/0. The only observable difference is that the tenant's data is gone.