chore(handover): Format markdown

Author: tizoc

core/summary.md

@@ -1,39 +1,53 @@
 # Core Crate Summary
 
-The core crate contains foundational infrastructure and shared utilities that all other crates depend on. We use this crate for shared types, utilities, and abstractions that need to be accessible across the entire project.
+The core crate contains foundational infrastructure and shared utilities that
+all other crates depend on. We use this crate for shared types, utilities, and
+abstractions that need to be accessible across the entire project.
 
 ## What This Crate Contains
 
-- **Substate System** (`src/substate.rs`): Type-safe access patterns for Redux state slicing and mutation control
-- **WASM Threading** (`src/thread.rs`): Main thread task delegation system needed for browser environments
-- **Network Configuration** (`src/network.rs`): Static network constants and config for mainnet/devnet
-- **Core Domain Types**: Basic blockchain types (blocks, SNARKs, requests, consensus) that everything uses
+- **Substate System** (`src/substate.rs`): Type-safe access patterns for Redux
+  state slicing and mutation control
+- **WASM Threading** (`src/thread.rs`): Main thread task delegation system
+  needed for browser environments
+- **Network Configuration** (`src/network.rs`): Static network constants and
+  config for mainnet/devnet
+- **Core Domain Types**: Basic blockchain types (blocks, SNARKs, requests,
+  consensus) that everything uses
   - `src/block/` - Block structures and validation
   - `src/snark/` - SNARK work and job management
   - `src/transaction/` - Transaction helper types and metadata
   - `src/consensus.rs` - Consensus types and fork decision logic
-- **Request Management** (`src/requests/`): Type-safe request ID generation and lifecycle tracking
-- **Channel Wrappers** (`src/channels.rs`): Abstractions over flume channels for message passing
-- **Distributed Pool** (`src/distributed_pool.rs`): BTreeMap-based data structure for network-synchronized state
+- **Request Management** (`src/requests/`): Type-safe request ID generation and
+  lifecycle tracking
+- **Channel Wrappers** (`src/channels.rs`): Abstractions over flume channels for
+  message passing
+- **Distributed Pool** (`src/distributed_pool.rs`): BTreeMap-based data
+  structure for network-synchronized state
 
 ## Technical Debt and Issues
 
 ### Medium Priority
 
 **Hardcoded Network Constants**
+
 - Fork constants are hardcoded in the `NetworkConfig` struct
 - Impact: Can't deploy flexibly, need code changes for network updates
 
 ### Low Priority
 
 **Unsafe Redux Access**
+
 - `unsafe_get_state()` method in `Substate` struct breaks Redux safety
 - Only used by the transaction pool state machine which requires refactoring
 
 **Inconsistent Error Handling**
+
 - Various instances of `panic!`, `unwrap()`, or `expect()` calls throughout core
 
 ## Known Limitations
 
-1. **Network Config**: Can't dynamically configure network parameters without code changes
-2. **WASM Constraints**: Browser limitations require specialized threading patterns
+1. **Network Config**: Can't dynamically configure network parameters without
+   code changes
+2. **WASM Constraints**: Browser limitations require specialized threading
+   patterns

docs/handover/ledger-crate.md

@@ -8,7 +8,8 @@ zkApp functionality, providing a direct port of the OCaml implementation. For
 developers familiar with the OCaml codebase, this maintains the same
 architecture and business logic while adapting to Rust idioms.
 
-For technical debt and critical issues, see [`ledger/summary.md`](../../ledger/summary.md).
+For technical debt and critical issues, see
+[`ledger/summary.md`](../../ledger/summary.md).
 
 ## Architecture
 
@@ -25,7 +26,8 @@ For technical debt and critical issues, see [`ledger/summary.md`](../../ledger/s
 
 - Port of OCaml's `Ledger.Mask` with identical copy-on-write semantics
 - Provides layered ledger views for efficient state management
-- Uses `Arc<Mutex<MaskImpl>>` for cheap reference counting; `Mask::clone()` is fast
+- Uses `Arc<Mutex<MaskImpl>>` for cheap reference counting; `Mask::clone()` is
+  fast
 - Used extensively in transaction processing to create temporary ledger states
 
 **Database** (`src/database/`)

ledger/summary.md

@@ -1,60 +1,79 @@
 # Ledger Crate Summary
 
-The ledger crate is the most complex component in the codebase. For architecture overview and design details, see [docs/handover/ledger-crate.md](../docs/handover/ledger-crate.md).
+The ledger crate is the most complex component in the codebase. For architecture
+overview and design details, see
+[docs/handover/ledger-crate.md](../docs/handover/ledger-crate.md).
 
 ## Quick Reference
 
 **Core Ledger**
+
 - `src/base.rs` - BaseLedger trait (fundamental interface)
 - `src/database/` - In-memory account storage
 - `src/mask/` - Layered ledger views with Arc-based sharing
 - `src/tree.rs` - Merkle tree operations
 
 **Transaction Processing**
+
 - `src/transaction_pool.rs` - Mempool with fee-based ordering
 - `src/staged_ledger/` - Block validation and transaction application
 - `src/scan_state/` - SNARK work coordination and parallel scan
 
 **Proof System**
+
 - `src/proofs/` - Transaction, block, and zkApp proof generation/verification
 - `src/sparse_ledger/` - Minimal ledger representation for proofs
 - `src/zkapps/` - zkApp transaction processing
 
 **Account Management**
+
 - `src/account/` - Account structures, balances, permissions
 
 ## Critical Issues
 
 **Error Handling**
-- Too many `.unwrap()` and `.expect()` calls in production code paths (excluding tests)
+
+- Too many `.unwrap()` and `.expect()` calls in production code paths (excluding
+  tests)
 - Critical transaction processing paths could panic the node
 - Inconsistent error handling across modules
-- Verification key lookup bug fix from upstream Mina Protocol needs to be ported (https://github.com/MinaProtocol/mina/pull/16699)
+- Verification key lookup bug fix from upstream Mina Protocol needs to be ported
+  (https://github.com/MinaProtocol/mina/pull/16699)
 
 **Monolithic Structure**
+
 - Single massive crate with files exceeding 6,000+ lines
 - Deep coupling between components that should be independent
 - Hard to maintain, test, and develop in parallel
 
 **Performance**
+
 - Excessive cloning of large structures in hot paths:
-  - `SparseLedger::of_ledger_subset_exn()` calls `oledger.copy()` creating unnecessary deep clones for sparse ledger construction
-  - Transaction pool operations clone transaction objects with acknowledged TODO comments about performance
-- No memory pooling or reuse strategies (could help with memory fragmentation in WASM)
+  - `SparseLedger::of_ledger_subset_exn()` calls `oledger.copy()` creating
+    unnecessary deep clones for sparse ledger construction
+  - Transaction pool operations clone transaction objects with acknowledged TODO
+    comments about performance
+- No memory pooling or reuse strategies (could help with memory fragmentation in
+  WASM)
 
 **Memory Management**
+
 - Memory-only implementation, no persistence for production
-- There's an unused `ondisk` implementation but we were planning a more comprehensive global solution (see persistence.md)
+- There's an unused `ondisk` implementation but we were planning a more
+  comprehensive global solution (see persistence.md)
 - Thread-local caching holds memory indefinitely
 
 ## Refactoring Plan
 
 **Phase 1: Safety**
+
 - Replace `.unwrap()` with proper error propagation in production code
 - Reduce cloning in hot paths
 - Standardize error types
 
-**Phase 2: Decomposition**
-Break into focused crates: `mina-account`, `mina-ledger`, `mina-transaction-logic`, `mina-scan-state`, `mina-transaction-pool`, `mina-proofs`
+**Phase 2: Decomposition** Break into focused crates: `mina-account`,
+`mina-ledger`, `mina-transaction-logic`, `mina-scan-state`,
+`mina-transaction-pool`, `mina-proofs`
 
-Changes must maintain strict OCaml compatibility while improving performance for production.
+Changes must maintain strict OCaml compatibility while improving performance for
+production.