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
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
//! **The config pane between frames** (bl-5c53; DESIGN §4.30) — which
//! destination it is pointed at, and the two reads that stand on it.
//!
//! # A struct of one question, and the question is which file
//!
//! `super::listing`'s three panes hold nothing; this one holds exactly one
//! thing — the destination — and it is an option inside the pane's own option
//! for `super::login`'s reason: *a subject with no pane* is unrepresentable
//! because the subject lives inside the pane. The pane opens pointed at
//! nothing, which is a real state an operator meets: the lineage listing is up
//! and no file has been asked for yet.
//!
//! # What is NOT held here is either answer
//!
//! [`Model::lineages`] and [`Model::config`] are the engine's, filed on the
//! model beside the roles and the provider table for their reason verbatim: a
//! pane that wrote its own bytes back would be painting a file the engine had
//! not written. That matters more here than anywhere else on this surface,
//! because the answer carries the engine's own JUDGEMENT of the values
//! (`crate::reply::config::Setting::fault`) and a seat that re-derived one
//! would be a second authority across a boundary.
//!
//! # The box is the write, and the seed is what makes the write ordinary
//!
//! A config write replaces a file's whole bytes (REMOTE §9.18: *"a typed edit
//! is a seat composing that text and applying it"*), so the act is the box —
//! and reaching it means having authored the file, which no mis-aimed click
//! does. That is why it takes DESIGN §4.20's ENABLEMENT and not its PLACE:
//! §4.20 is for an act whose subject ceases to exist, and this one's subject
//! is a file that still exists afterwards holding text the operator wrote.
//!
//! What is NOT ordinary about it is the thing the wire dropped. Upstream's
//! editors carry a hash guard because *"a long-lived RAM draft"* can be
//! written over a file that moved under it, and a `config` act *"carries no
//! hash guard, and needs none"* because a gesture states its whole text in one
//! atomic instruction — true of the gesture and false of the OPERATOR, who
//! types for minutes while a standing read replaces the answer underneath
//! them. [`Draft::seed`] is that guard restated as a READING rather than as a
//! refusal, which is this seat's whole division of labour: the pane says the
//! file went somewhere else, and the engine remains the only thing that
//! judges.
//!
//! # Both reads STAND, and the second only once a file is picked
//!
//! A config file changes under the operator — a `litany config` from any seat,
//! an agent's own edit, a lineage that advanced — so the read that says what it
//! holds is worth nothing unless it is asked again. The lineage listing stands
//! on the pane and the file read stands on the destination, which is
//! `crate::state::Open::Config`'s own shape.
/// The box's own two readings, split from the pane's state at the design-time
/// budget on the seam they already have: this file is *what the pane is
/// pointed at*, and that one is *what the box and the file have to say to each
/// other*.
pub use Draft;
use Model;
use crateWhere;
/// The config pane, while it is open.