FG-0408 Dual-Lane Session Architecture
Description
Running parallel session lanes with distinct domain boundaries, where each lane has its own identity, scope, and update protocol. The key insight beyond basic multi-session is that sessions need domain boundaries as well as coordination protocols. Each lane owns a domain and cannot accidentally modify the other's state. Coordination happens through shared state files rather than direct session interaction.
Implementation
Define your lanes by domain, not by task. Each lane gets a name, a scope boundary, and a list of what it owns. Establish a shared state file (STATUS.md or equivalent) that both lanes read and update. Neither lane touches files or systems owned by the other. When lanes need to communicate, they do it through the shared state, never through direct session interaction. Review lane boundaries when domain scopes shift.
Success Indicators
- Zero cross-lane conflicts over sustained operation
- Each lane can describe its domain boundary without ambiguity
- Shared state is the only coordination mechanism, and it works reliably
- Both lanes ship independently without blocking each other
Failure Modes
- Lanes defined by task instead of domain, leading to boundary violations when tasks overlap
- Shared state becomes a bottleneck or source of conflicts
- Lanes diverge in context, losing awareness of what the other has shipped
- Over-coordination: lanes spending more time syncing than working
Sub-Methods 3
Explicitly define what each lane owns: which files, which systems, which concerns. The boundary is a contract. If it is ambiguous, lanes will collide. Write it down and enforce it.
Define how the shared state file is read and updated. Each lane reads at session start, updates at session end. If the state has changed since you read it, incorporate those changes before overwriting. The protocol prevents lost updates without requiring real-time coordination.
Give each lane a name and identity that makes the domain obvious. BUILD/SHIP, TRAIN/DEPLOY, EXPLORE/HARDEN. The name should immediately communicate what the lane does and does not own. Identity prevents scope drift.