Describe the bug
Session forking has a stub/placeholder implementation but is not yet functional.
Current state
crates/core/src/fork.rs contains the fork admission logic and inherited segment construction, but several fields are placeholders:
source_parent_session_id: SessionId::new() — uses a new random ID instead of the actual parent
source_range: SegmentSourceRange { start_offset: 0, end_offset: 0 } — always zero
segment_hash: String::new() — empty hash
The fork is not exposed via any Desktop or TUI UI, and the full replay-with-independent-segments flow described in the module's doc comment is not wired up.
Expected behavior
- Users can fork a session from the Desktop app (at a specific turn)
- Forked sessions retain inherited history correctly
- Independent segment loading works for forked sessions
Related component
crates/core/src/fork.rs
crates/protocol/src/acp_session.rs
Describe the bug
Session forking has a stub/placeholder implementation but is not yet functional.
Current state
crates/core/src/fork.rscontains the fork admission logic and inherited segment construction, but several fields are placeholders:source_parent_session_id: SessionId::new()— uses a new random ID instead of the actual parentsource_range: SegmentSourceRange { start_offset: 0, end_offset: 0 }— always zerosegment_hash: String::new()— empty hashThe fork is not exposed via any Desktop or TUI UI, and the full replay-with-independent-segments flow described in the module's doc comment is not wired up.
Expected behavior
Related component
crates/core/src/fork.rscrates/protocol/src/acp_session.rs