Document MVP persistence limitations
This commit is contained in:
@@ -479,6 +479,27 @@ stop the server, preserve the suspect save, restore the newest timestamped
|
||||
backup, restart, validate the world, and only then allow a new manual/admin
|
||||
save.
|
||||
|
||||
## MVP Persistence Limitations
|
||||
|
||||
Version 0.1.M persistence is intentionally file-based and MVP-scoped.
|
||||
|
||||
Current limitations:
|
||||
|
||||
- no database-backed world state yet;
|
||||
- no account-provider identity binding yet;
|
||||
- no save migration framework beyond simple versioned records;
|
||||
- no automated corrupted-save validator yet;
|
||||
- no placed-container actor capture yet, only a reserved container save schema;
|
||||
- no full offline player simulation or family/generational simulation yet;
|
||||
- no cross-server persistence or shard transfer yet;
|
||||
- no external backup replication unless VM/project backup jobs include
|
||||
`Saved/SaveGames`;
|
||||
- no player-facing save/load UI yet;
|
||||
- no compatibility guarantee for pre-MVP experimental save files.
|
||||
|
||||
These limits are acceptable for the first playable MVP as long as they remain
|
||||
visible in handoffs, investor/demo notes, and release checklists.
|
||||
|
||||
## Testing Gates
|
||||
|
||||
Minimum persistence smoke test:
|
||||
|
||||
Reference in New Issue
Block a user