The snapshot question is answered by a test

The lifecycle design asked whether a scenario snapshot needs the machines
stopped. The integration test answered it on its first run: no, but they
must be flushed.

A snapshot captures disk and not memory, so a write still in the guest's
page cache is absent from it — not stale, absent. A file written seconds
before a snapshot did not survive the restore.

Flushing first buys write-durability. It does not buy
application-consistency: anything mid-transaction is still captured
mid-transaction, and that limit is now stated rather than left implied.

03-DESIGN/01-to-be/03-scenario-lifecycle.md

@@ -133,6 +133,12 @@ decision rather than a second implementation.
   [research 010](../../01-RESEARCH/010-lab-inner-loop-cost/measurements.md).
 - **Instance naming.** A declaration is a kind and instances are many; how they are named
   decides whether a person can find the one they left standing yesterday.
+- ~~**Does a scenario snapshot need the machines stopped?**~~ **Answered by the integration
+  test on its first run: no, but they must be flushed.** A snapshot captures disk and not
+  memory, so a write still in the guest's page cache is absent from it — not stale, absent. A
+  file written seconds before a snapshot did not survive the restore. Flushing first buys
+  write-durability; it does not buy application-consistency, and anything mid-transaction is
+  still captured mid-transaction.
 - **What survives `destroy`.** Logs and captures are the output of a failed run, so destroying
   the instance must not destroy them.
 - **Placement before the mesh is self-hosting.** `place:` needs artifacts from somewhere, and