1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
//! Global RYO storage for session persistence and replay.
//!
//! This module provides persistent storage for session transaction logs,
//! enabling **Git-like reproducibility**: given an initial state and a sequence
//! of mutations, the same result can be deterministically reproduced.
//!
//! # Architecture Overview
//!
//! The storage system is designed with a **3-layer architecture** inspired by
//! [Command Sourcing] and [Event Sourcing] patterns from game simulation systems:
//!
//! ```text
//! ┌─────────────────────────────────────────────────────────────────────────┐
//! │ Layer 1: Mutation (Functional Layer) │
//! │ ───────────────────────────────────────────────────────────────────── │
//! │ - trait Mutation { apply(), describe(), ... } │
//! │ - Maximum extensibility: 100+ mutation types supported │
//! │ - No serialization responsibility │
//! │ - See: ryo_mutations │
//! └─────────────────────────────────────────────────────────────────────────┘
//! ↓ generates at execution time
//! ┌─────────────────────────────────────────────────────────────────────────┐
//! │ Layer 2: MutationRecord (Recording Layer) │
//! │ ───────────────────────────────────────────────────────────────────── │
//! │ - Serializable record of each mutation │
//! │ - Contains: MutationSpec + StateRef(pre) + StateRef(post) │
//! │ - Enables determinism verification during replay │
//! │ - See: crate::txlog::TxAction::MutationApplied │
//! └─────────────────────────────────────────────────────────────────────────┘
//! ↓ references
//! ┌─────────────────────────────────────────────────────────────────────────┐
//! │ Layer 3: StateStore (State Layer) │
//! │ ───────────────────────────────────────────────────────────────────── │
//! │ - Content-addressed storage for file states │
//! │ - Like GPU textures: managed separately but composable │
//! │ - Immutable: StateRef = hash of content │
//! │ - See: StateRef, StateStore │
//! └─────────────────────────────────────────────────────────────────────────┘
//! ```
//!
//! # Design Principles
//!
//! ## Command Sourcing with Verification
//!
//! Unlike pure Command Sourcing (which requires determinism) or pure Event
//! Sourcing (which stores results), we use a **hybrid approach**:
//!
//! ```text
//! MutationRecord = MutationSpec + pre_state + post_state
//! (Command) (验证用) (验证用)
//! ```
//!
//! - **MutationSpec**: The "what" - serializable mutation intent
//! - **pre_state**: Expected state before mutation (for verification)
//! - **post_state**: Expected state after mutation (for verification)
//!
//! This allows:
//! 1. **Normal replay**: Apply mutations sequentially
//! 2. **Verified replay**: Check pre/post states match expectations
//! 3. **Partial replay**: Start from any checkpoint with known state
//!
//! ## Comparison with Git
//!
//! | Concept | Git | RYO |
//! |-------------|------------------------|-------------------------------|
//! | State | Blob (content-hashed) | StateRef (content-hashed) |
//! | Operation | Diff (computed) | MutationSpec (recorded) |
//! | History | Commit chain | TxLog (MutationRecord chain) |
//! | Checkpoint | Tag/Branch | Named Snapshot |
//!
//! Key difference: Git stores **states**, RYO stores **operations**.
//! But both can reconstruct history through their chain.
//!
//! # Replay Flow
//!
//! ```text
//! 1. Load initial state from StateStore (or checkpoint)
//! 2. For each MutationRecord in TxLog:
//! a. (Optional) Verify current state == record.pre_state
//! b. Reconstruct Mutation from MutationSpec
//! c. Apply mutation: state' = mutation.apply(state)
//! d. (Optional) Verify state' == record.post_state
//! 3. Final state is the replay result
//! ```
//!
//! # Directory Structure
//!
//! ```text
//! ~/.ryo/
//! ├── sessions/ # Session transaction logs
//! │ ├── {uuid}.txlog.json
//! │ └── ...
//! ├── states/ # (Future) Content-addressed state storage
//! │ ├── ab/cd1234... # Sharded by hash prefix
//! │ └── ...
//! ├── index.json # Session metadata index
//! └── config.toml # (Future) Global configuration
//! ```
//!
//! # Usage
//!
//! ```ignore
//! use ryo_core::storage::{RyoStorage, StateRef, StateStore};
//! use ryo_core::txlog::TxLog;
//!
//! // Create global storage
//! let mut storage = RyoStorage::global()?;
//! storage.ensure_init()?;
//!
//! // Dump a session
//! let log: TxLog = /* ... */;
//! let session_id = storage.dump(&log)?;
//!
//! // Load and replay
//! let loaded = storage.load(&session_id)?;
//! loaded.replay(&state_store)?;
//!
//! // Query sessions
//! let all = storage.list_sessions()?;
//! let project_sessions = storage.sessions_for_project(Path::new("/my/project"))?;
//! ```
//!
//! # References
//!
//! - [Command Pattern - Game Programming Patterns](https://gameprogrammingpatterns.com/command.html)
//! - [Event Sourcing - Martin Fowler](https://martinfowler.com/eaaDev/EventSourcing.html)
//! - [Command Sourcing vs Event Sourcing](https://thinkbeforecoding.com/post/2013/07/28/Event-Sourcing-vs-Command-Sourcing)
//!
//! [Command Sourcing]: https://thinkbeforecoding.com/post/2013/07/28/Event-Sourcing-vs-Command-Sourcing
//! [Event Sourcing]: https://martinfowler.com/eaaDev/EventSourcing.html
pub use AutoSaveLogger;
pub use ;
pub use ;
pub use ;
pub use TxLogMode;
pub use ;
pub use ;
pub use ;