From ec40f146aaf8e8bcc9e88c058cb5a591ef3bd3e8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9?= Date: Wed, 7 Oct 2026 18:05:53 +0500 Subject: [PATCH] Phase 9.1: document the checkpoint after a restart Co-Authored-By: Claude Sonnet 5.5 --- docs/PORTABLE_PLAYER_MODE.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/docs/PORTABLE_PLAYER_MODE.md b/docs/PORTABLE_PLAYER_MODE.md index ba94818..731b0fe 100644 --- a/docs/PORTABLE_PLAYER_MODE.md +++ b/docs/PORTABLE_PLAYER_MODE.md @@ -47,7 +47,7 @@ engines unchanged: store, realm::{import,upd * The runtime is started with the application (`start_portable`) and stopped on `RunEvent::Exit`; it is independent of the screen, so navigating away changes nothing. * The Owner and Host stores live under `/portable/{owner,host}`. A restart resumes sessions, the outbox and the progression pins from them; `HostMemory` keeps the - Host's in-memory throttling between ticks. The first tick after a restart checkpoints at once. + Host's in-memory throttling between ticks. After a restart the Host has no memory of its last checkpoint and checkpoints at once; that checkpoint makes a canonical revision only if the character really differs (section 8). * One operation at a time (`busy`); status derivation is a pure function of stores + observations (`copy_status`). * `COA_MANAGER_DATA_DIR` overrides the data folder (development and tests only). @@ -104,3 +104,19 @@ the recent errors. No credentials, no snapshots, no inventory. * The Tauri window was driven over WebView2's DevTools protocol on a fresh data folder: add descriptors, make portable, preflight with the projection warning, Play, status chips, navigation away and back, a Manager restart in the middle of a session, logout and the saved version, history wording. * Not covered by automation: the real game client (needs the owner's run, see the report). + +## 8. Checkpoints after a restart (Phase 9.1) + +The immediate checkpoint after a Manager/Host restart stays: it is the safety net for whatever happened while nobody watched. The Owner makes a canonical revision from a +checkpoint only when `merge3(C0, B0, B1)` differs from the head by `content_hash`; a checkpoint that reproduces the head is acknowledged (`Applied`) and the revision stays. + +Investigated on a real worldserver (cap 60, bot AI suspended with `botcmd suspend` so that nothing but the realm acts) and on the owner's real-client store: the restart itself +adds nothing. The revisions seen "for no reason" were the **first checkpoint of a first login on a realm**, which carries what the realm itself did to the imported character +after `B0` (default build slot `core.ascension_slot.0`, flight paths, class/mount spells such as 6654/23250/32243/32246, explored areas) and, with a bot standing in for the +player, the bot's own activity (exploring, an auto-accepted quest). Those are real character state, so they belong in the canonical character; a second login on the same realm +shows none of them. Logging out with nothing changed also makes no revision. + +Regression tests: `session::tests::the_immediate_checkpoint_after_a_host_restart_makes_no_revision_when_the_character_did_not_change` (fake realm, file-backed Host: checkpoint N, +restart, immediate checkpoint `Applied`, revision unchanged field by field and by hash, then a real change makes exactly N+1) and the live +`service::live_service::a_manager_restart_with_nothing_to_report_makes_no_revision_and_a_real_change_makes_exactly_one` (real worldserver, `PortableService` reopened mid-session, +`botcmd professiontrainer` as the gameplay change).