docs(getting-started): say which snapshot rig launch restores a kernel seat from

The line said `rig launch kernel <logical id>` restores from the kernel's latest restore-usable snapshot. Restore ranks automatic snapshots (taken before `rig down`, on the periodic schedule, or at a runtime switch) first, then the newest, skipping unusable ones, so an older automatic snapshot wins over a newer manual one. It now says so, names what `--plan` shows (the snapshot picked and any newer usable one) and `--snapshot-id`, and says the resume holds under the default restore policy, which the kernel's seats keep.
2026-11-12 01:41:39 -10:00 · 2026-11-12 06:05:21 +00:00
1 changed files with 7 additions and 2 deletions
@@ -347,8 +347,13 @@ with `rig up kernel --existing`. A seat you stopped or unclaimed also stays down
 While the kernel's other seats are running, `rig up kernel --existing` refuses
 (it restores only a kernel with no live session), so start one stopped seat with
 `rig launch kernel <logical id>` (`--plan` first). It restores that seat from the
-kernel's latest restore-usable snapshot and resumes its saved conversation; a seat
-it can't resume is reported as waiting for a decision, not as started.
+kernel snapshot that restore ranks first: the newest usable automatic one (taken
+before `rig down`, on the periodic schedule, or at a runtime switch), even when a
+manual one is newer, and otherwise the newest usable one. `--plan` names the
+snapshot it picked and any newer usable one, and `--snapshot-id <id>` picks one
+yourself. Under the default restore policy, which the kernel's seats keep, it
+resumes the seat's saved conversation; a seat it can't resume is reported as
+waiting for a decision, not as started.
 `rig seat launch <seat> --fresh --reason "…"` instead starts a new conversation
 with no continuity source: use it only when you want a fresh occupant, since the
 seat's earlier conversation isn't carried.