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
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
//! **The tool window** (yog's `docs/REMOTE.md` §5.5, PROTOCOL 15) — what is
//! running, where, and what it came back with, on the lane an operator has
//! open while it happens.
//!
//! # Two entries per call, and both are transitions
//!
//! The engine appends one entry as a call is dispatched (its name and its
//! bounded input) and another when the capture lands (its exit code), because
//! litany writes `input.json` and `output.json` at exactly those two moments —
//! the pair of file existences *is* the window opening and closing. So the
//! wire carries transitions and this end holds **calls**: [`fold`] merges the
//! two halves onto one [`Window`] keyed by [`Window::tool_use`], which is what
//! lets the closing entry restate neither the name nor the input.
//!
//! # Presence is the status, and there is no third reading
//!
//! [`Window::exit_code`] absent is a call **in flight**; present is one whose
//! capture landed. REMOTE §5.5 is explicit that there is no arm for *complete,
//! status unknown*, which is what makes the two readings impossible to
//! disagree about.
//!
//! # A third transition never reaches disk, and it is the park
//!
//! [`Window::held`] (REMOTE §5.5, PROTOCOL 18; yog bl-58bb) carries the
//! capability control's reason for parking the call. It is not a third file:
//! a held invocation is stopped *before* the executor is entered, so litany
//! lands neither `input.json` nor `output.json` and the two entries above say
//! nothing at all — the engine reads the park off the conversation's own hold
//! mark instead. Its presence is the status, `exit_code`'s own discipline on
//! the same entry, so a held call is never also an opening. The park is not
//! terminal: when the operator answers it, the call runs and its opening and
//! closing arrive under this same `tool_use`, which [`fold`] merges onto the
//! one call the way it merges any other transition.
//!
//! # Where it ran is in the name, and this end must not take it apart
//!
//! REMOTE §5.1 presents a loaded remote tool as `<client>_<tool>`, always and
//! never only when ambiguous, so `box2_Bash` says the box as well as the tool.
//! The engine does not split that composition back apart and neither does
//! this: the registry answers *where a call would route now*, which is a
//! different question from where this one ran.
use ;
use fields;
/// The key the window rides under, beside the fold rather than inside it.
pub const TOOLS: &str = "tools";
/// The three fields an entry can carry beside its id.
const TOOL: &str = "tool";
const INPUT: &str = "input";
const EXIT_CODE: &str = "exit_code";
const HELD: &str = "held";
/// **One tool call, as much of it as has been said.**
/// The window a frame carries. **Required, empty list included** (REMOTE
/// §5.5): absent would make *this build has no tool window* and *nothing ran
/// since the last frame* one shape, which is the reassuring answer on exactly
/// the build that cannot tell.
pub
/// One transition.
/// **Merge one transition into the calls held so far**, keyed by the id both
/// halves carry — the whole of how a closing entry that restates nothing is
/// still read as the end of a named call.
pub