jschoubben
8efa063f21
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
The mesh being built toward. Every statement here traces to a record in
02-DECISIONS/; nothing arrives by drafting.
A document here describes an intention. What currently runs is in
00-as-is/, and the two are never merged — when something ships, the as-is
document is written and this one's status becomes implemented.
| Document | Covers | Rests on |
|---|---|---|
00-work-breakdown.md |
How the decomposition gets built, in what order, and where a human must look | ADR 0015 |
01-end-to-end-testing.md |
The lab: a real mesh a change can be run against before it reaches nodes | ADR 0016, 0029 |
02-scenario-declaration.md |
What a scenario declares — the underlay, and what to place on it | ADR 0031 |
03-scenario-lifecycle.md |
What happens to a scenario — raise, snapshot, restore, move, destroy | ADR 0032 |
04-lab-installation.md |
Getting the lab onto a clean machine, and why it verifies capability rather than installation | ADR 0008 |
Not yet written
- The eight bounded contexts. ADR 0015 decides the decomposition; the per-context specifications do not exist yet. The work breakdown says in what order they are needed.
- Domain grouping outside the core. ADR 0017 settles the principle and explicitly does not settle the domain list. That is a research effort, not a design document, until it concludes.