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
//! RFC 010 PR-4 — openraft adapter.
//!
//! ## Sub-PR layout (this PR is PR-4-a)
//!
//! | Sub-PR | Module | Purpose |
//! |---|---|---|
//! | **4-a (this)** | [`types`] | Type config + log-entry wrapper + node id/info. No I/O. |
//! | 4-b | `log_storage` | `RaftLogStorage` over `memory_commit_log`. |
//! | 4-c | `state_machine` | `RaftStateMachine` + snapshot. |
//! | 4-d | `network`, `committer` | HTTP `RaftNetwork` + `RaftCommitter` exposing [`crate::commit::MutationCommitter`]. |
//! | 4-e | (tests) | 3-node cluster boot, leader-kill failover, partition heal. |
//!
//! ## Why split openraft adoption into 5 sub-PRs
//!
//! openraft has four orthogonal trait surfaces (`RaftLogStorage`,
//! `RaftStateMachine`, `RaftNetwork`, plus the type config that ties
//! them together). Implementing all four in one PR would mean ~2000 LOC
//! of trait satisfaction with no test coverage until the very end —
//! exactly the kind of half-baked replication adapter the gpt-5.5
//! redteam flagged as the #1 architectural risk for YantrikDB.
//!
//! The split lets each sub-PR ship green tests and an isolated unit of
//! correctness: 4-a pins the wire types, 4-b verifies log durability
//! against `memory_commit_log`, 4-c verifies state-machine apply, 4-d
//! wires the network + committer, 4-e proves the whole thing under
//! Jepsen-style partition.
//!
//! ## What this sub-PR (4-a) does NOT include
//!
//! - No openraft `RaftLogStorage` impl yet (4-b).
//! - No state-machine apply (4-c).
//! - No network transport (4-d).
//! - No `RaftCommitter` wrapping `MutationCommitter` (4-d).
//! - No mTLS gate enforcement on cluster mode (4-d ties this to RFC 014-A).
pub use ;
pub use RaftCommitter;
pub use ;
pub use SqliteRaftLogStorage;
pub use ;
pub use ;
pub use ;
pub use ;