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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
//! Where a notch lands **in the chat** (bl-1802) — the pairing that makes the
//! boundary rule and the notch one thing rather than two drawings of one fact.
//!
//! **The bug this replaces.** Both the old crossings derivation (bl-929d) and
//! the old pin cut (bl-98da) paired *the i-th maximal run of delivered `.md`
//! entries* with *the i-th step*, on the stated ground that "drains and steps
//! are serialized under litany's executor lock". Serialization gives order, not
//! a bijection, and the two sets are nowhere near the same size: litany's step
//! is **one model call** (`StepOutcome::ToolsRan` re-enters `advance` for the
//! next one — litany ARCH §2.3 step 3), while a boundary drain lands delivery
//! commits only when the inbox holds something. A turn that calls five tools is
//! five steps behind one delivered run, so from the second tool-using turn
//! onward every rule carried the wrong commit and every pin cut the transcript
//! in the wrong place. **The sets were never the same set.**
//!
//! **What pairs exactly.** A model call that reaches `Finish` seals its output
//! and the executor commits it as `messages/NNN-<model-id>.json` (litany ARCH
//! §2.3 *The transcript writer*); a call that errors, is killed, or is still
//! open commits nothing. So the transcript's model entries are exactly the
//! steps whose framing is [`Framing::Complete`], **in step order, one for
//! one** — the pairing below, needing no new read on either side.
//!
//! Each step therefore owns the run of entries between its predecessor's model
//! output and its own: the tool results its predecessor's calls resolved and
//! whatever the boundary drain delivered (ARCH §2.11 orders the drain after the
//! tool entries). That run's first row is where the step's rule paints, and the
//! index of its own model output is the cut its pin reads to.
//!
//! **A step that sealed nothing has a place only when it is the last one.**
//! The running call's read state is everything committed so far, so it marks
//! the tail of the chat — which is where a child dispatched right now hangs its
//! card. A *superseded* call that sealed nothing (a crash, then a revival
//! deposit re-driving the branch) produced no output to sit above and left no
//! place: the notch stays on the spine, and the revival's own rule is the next
//! line down.
use crateFraming;
use crateStepSummary;
use crate;
/// One notch's place in the chat: the row its rule paints above, and how much
/// of the transcript that call had read. Both are positions in one sequence —
/// derived per snapshot from the entries and the step spine, stored nowhere.
/// Each step's place in `transcript`, parallel to `steps`. `None` is a notch
/// the chat has no seat for — see the module note; it is a value, not an arm.
pub
/// Index of the first model-output entry at or after `from` — the entry the
/// ensuing call sealed, and therefore the end of what it read.