# Browser VM Snapshot Strategy

Use this file when deciding how to preserve and clone browser VM images.

## Runtime classes

### personal-workspace

Examples:

- `xfce`
- later `kde` if used as a real user workspace

Policy:

- persistent
- manual milestone snapshots
- optional light periodic retention
- do not auto-reset after each run

### automation-base

Examples:

- `base-tmux`
- `browser`

Policy:

- stable source image
- snapshot at milestones only
- use as the source for disposable clones

Snapshot points:

- after Debian Trixie install
- after package update
- before GUI or browser profile installation

### automation-runner

Examples:

- per-task clone used by an agent for browser automation

Policy:

- disposable
- derived from `automation-base`
- no normal Sanoid retention
- destroy after run or rollback to the base snapshot
- keep only exported artifacts and logs

## Derived profile policy

Profiles such as `browser`, `xfce`, `i3`, and `kde` should be built from a known source snapshot.

Examples:

- `@fresh-install-08-mar-2026`
- `@post-update-08-mar-2026`
- `@pre-xfce-08-mar-2026`
- `@pre-kde-08-mar-2026`

## Clone policy

Clones should come from a clean source snapshot, not from random running state.

This keeps agent-created desktops reproducible.

## Important distinction

Sanoid helps protect persistent bases.

It does not replace clone and reset logic for disposable runners.
