git_policy_cli/
replay_capture_order.rs

1//! What:
2//!  The capture-order decision for one shared path of a replay.
3//! Why:
4//!  When the prepared commit and every landed commit that changed a path captured it from the same worktree,
5//!       the later capture's bytes land, which is what sequential native commits record from the shared disk.
6//!       Every other path keeps subsumption and then the three-way merge. The service decides it from the capture stamps it
7//!       keeps (`service_captures.rs`); this is the answer's shape.
8//!
9//! In TS you'd write (pseudocode):
10//! ```ts
11//! type CaptureOrderDecision = 'prepared' | 'landed' | 'unordered';
12//! ```
13
14/// What:
15///  The capture-order decision for one shared path.
16/// Why:
17///   Replay acts on the three answers differently: the prepared entry lands, the landed entry stays,
18///       or subsumption and the merge decide.
19///
20/// In TS you'd write (pseudocode):
21/// ```ts
22/// type CaptureOrderDecision = 'prepared' | 'landed' | 'unordered';
23/// ```
24#[derive(Clone, Copy, Debug, Eq, PartialEq)]
25pub enum CaptureOrderDecision {
26    /// The prepared commit captured later: its entry lands.
27    Prepared,
28    /// A landed commit captured later: the landed entry stays.
29    Landed,
30    /// Capture order does not apply: subsumption, then the three-way merge.
31    Unordered,
32}
git_policy_cli/replay_capture_order.rs

git_policy_cli/
replay_capture_order.rs
