docs: mark quicksave phase complete

docs/LEARNING_ROADMAP.md

@@ -641,17 +641,18 @@ Completed after the architecture gate:
 - deterministic structured economic events for extraction, deposit,
   withdrawal, and consumption;
 - persisted event identity/history and a visible carried-food prop derived
-  from NPC inventory.
+  from NPC inventory;
+- a validated local quicksave with bounded file size, guarded slot names,
+  atomic replacement recovery, F5/F9 controls, and active-visual rebuilding.
 
 The practical next sequence is:
 
-1. Add save-slot persistence, validation, and explicit migration fixtures
-   before schedules
-   or social state expand.
-2. Resume Terrain3D sculpting, runtime integration, and the simulation-garden
+1. Resume Terrain3D sculpting, runtime integration, and the simulation-garden
    beauty pass.
-3. Add stylized character and profession readability plus the reason
+2. Add stylized character and profession readability plus the reason
    inspector.
+3. Expand persistence only when schedules, player state, or a real save menu
+   creates a concrete requirement.
 
 This order strengthens the simulation while regularly producing visible
 progress suitable for public development updates.

docs/PROJECT_CONTEXT.md

@@ -502,8 +502,9 @@ These are expected prototype constraints, not necessarily isolated bugs:
   marker mapping and several action effects remain hard-coded.
 - Temporary activity markers remain for eating, rest, study, and patrol; NPC
   and player food/wood gathering use `ResourceNode` instances with no fallback.
-- Current NPC, village, resource, clock, and RNG state serialize through schema
-  v1, but there is no save-slot/file UX or top-level backward migration yet.
+- Current NPC, village, resource, storage, event, clock, and RNG state serialize
+  through world schema v3. F5/F9 provide one validated local quicksave; a save
+  menu, metadata, and player-transform persistence remain deferred.
 - Simulation-owned resource records retain live amounts, reservations, and
   usage definitions while ResourceNode scenes are unloaded.
 - An explicit fixed-step clock converts frame delta into simulation ticks, but
@@ -741,8 +742,9 @@ The location-based food loop is complete and traceable: gathering creates
 carried food, depositing fills the pantry, withdrawal retrieves one unit, and
 eating consumes it. Each successful transfer creates a persisted structured
 event, and active NPCs visibly carry food through presentation derived from
-their inventory. The next systems milestone is save-slot persistence and
-validation. Bounded Terrain3D look-development can resume alongside it.
+their inventory. The bounded save-slot slice is also complete, including
+validation, atomic replacement recovery, and active-visual rebuilding.
+Terrain3D runtime integration and the simulation-garden beauty pass are next.
 
 The coherent visual slice can then aim for:
 

docs/SIMULATION_STATE_SCHEMA.md

@@ -87,15 +87,26 @@ ResourceStateRecord v2 adds the definition facts needed while unloaded. Nested
 v1 resource records are migrated explicitly and hydrate their missing
 definition from a matching presentation node when one becomes available.
 
+## Local quicksave boundary
+
+`SaveSlotStore` writes the existing versioned JSON record to
+`user://saves/quicksave.json`. It validates the serialized record before
+replacement, limits file size, restricts slot names, preserves the previous
+file during replacement, and can recover that backup if replacement is
+interrupted. Loading parses and validates the complete record before mutating
+the simulation.
+
+In `main.tscn`, F5 saves and F9 loads this slot. Restoration rebuilds active NPC
+visuals from authoritative state.
+
 ## Deliberately out of scope
 
 This phase does not yet provide:
 
-- save-slot files, metadata, thumbnails, or atomic disk writes;
+- a save-slot menu, metadata, thumbnails, autosaves, or multiple profiles;
 - migrations older than the explicitly supported world schemas v1 and v2;
 - player inventory, relationship, schedule, or social-memory records;
-- a player-facing load flow;
-- save-slot persistence for scene-independent resource state.
+- persistence for the player transform or presentation-only scene state.
 
 Those features should build on this boundary rather than inventing parallel
 serialization paths.